Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TS] Generate imports rule when using a "ParamObject" from another file #4025

Closed
MangelMaxime opened this issue Jan 27, 2025 · 7 comments · Fixed by #4048
Closed

[TS] Generate imports rule when using a "ParamObject" from another file #4025

MangelMaxime opened this issue Jan 27, 2025 · 7 comments · Fixed by #4048

Comments

@MangelMaxime
Copy link
Member

@Freymaurer reported to me that we don't have import the type when consuming a "ParamObject" defined in another file which results in a TS compilation error.

Related to the work done in #4007

@Freymaurer
Copy link
Contributor

@MangelMaxime Can you point me to some examples on the import rules? Then i can have a look at it.

@alfonsogarciacaro
Copy link
Member

A tricky thing here is the semantics of the attributes is being challenged. Global/Import were intended to import types from the outside to F#, and now we want to use it export code from F# to the outside.

At this point, if #4007 has only been released in alpha the Global/ParamObject/Emit combination could be reduced to a single attribute, say PojoDefinedByConsArgs or similar. Then we should get exports automatically and we can also establish constraints (no secondary constructors, no inheritance, no interface implementation).

@MangelMaxime If you agree with that I can try to adapt your work in #4007 in this sense.

@MangelMaxime
Copy link
Member Author

@MangelMaxime If you agree with that I can try to adapt your work in #4007 in this sense.

Feel free to have a look, I mostly tried to fix the code gen but still don't know all the internal.

Then we should get exports automatically and we can also establish constraints (no secondary constructors, no inheritance, no interface implementation).

The current implementation tried to cover all the cases, and it kind of works. The best solution would be to generate real interface inheritance or JSDoc to propagate correctly but the union type does the jobs (just JSDoc is useless in this cases).

@MangelMaxime
Copy link
Member Author

@Freymaurer Should be fixed with 5.0.0-alpha.10

@Freymaurer
Copy link
Contributor

Awesome will test it tomorrow! 🚀

@Freymaurer
Copy link
Contributor

Seems like fable expects to find a type reflection information for my [<Pojo>]:

[<Pojo; AllowNullLiteral>]
type Term (?name: string, ?id: string, ?description: string, ?source: string, ?href: string, ?isObsolete: bool, ?data: obj) =
    member val name: string option = name with get, set
    member val id: string option = id with get, set
    member val description: string option = description with get, set
    member val source: string option = source with get, set
    member val href: string option = href with get, set
    member val isObsolete: bool option = isObsolete with get, set
    member val data: obj option = data with get, set

Image

This was triggered by using the pojo as field in a record type:

type private TermSearchResult = {
    Term: Term
    IsDirectedSearchResult: bool
}

producing the following reflection for the record type (note Term_$reflection()):

function TermSearchResult_$reflection(): TypeInfo {
    return record_type("Swate.Components.TermSearchResult", [], TermSearchResult, () => [["Term", Term_$reflection()], ["IsDirectedSearchResult", bool_type]]);
}

@alfonsogarciacaro
Copy link
Member

Indeed, reflection should ignore Pojos as it does with other erased types. I sent #4048 for it.
I was tempted to edit all places when isErasedOrStringEnum is called but I was afraid to break something so let's make a surgical change for now.

alfonsogarciacaro added a commit to alfonsogarciacaro/Fable that referenced this issue Feb 17, 2025
MangelMaxime added a commit that referenced this issue Feb 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants