-
Notifications
You must be signed in to change notification settings - Fork 53
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
Support for @inline fragments #116
Comments
|
Yes, I am referring to readInlineData. |
Let me try and bind it real quick and get back to you... 😄 |
This is as far as I got.
But I cant get type type |
I think what we should do isn't binding it in general, but rather generate code for it via the generated fragment module only when the fragment has
Are you following how I'm thinking? I'll give it a try now and see if I can get it together real quick. |
Yes, I follow, so we need to add it in the ppx, that's where you lose me 😬 |
I am not that comfortable adding it to ppx but I am willing to try. |
Give me a few minutes here and I'll have something you can review and hopefully get some insight on my thinking around adding stuff to the PPX, and then I can guide you through doing it yourself for the next feature we want to bind that touches the PPX, if you're interested? |
yes! very interested. |
Check this out: https://github.com/zth/reason-relay/compare/bind-read-inline Is that making sense? I haven't actually tested it yet so it might not work 😅 |
...I'm making a few changes to that, bear with me a few more minutes. |
This looks good to me! Thank you for responding so quickly! I will try it out locally when I get a change. |
Implemented in #117 |
How would reason-relay tackle supporting inline fragments? So non-react function can take advantage of data masking and getting correct reason types?
I tried binding it myself but was not successful since I could not find out how to get the module type that
[%relay.fragment]
The text was updated successfully, but these errors were encountered: