Fork me on GitHub

Hello. I'm trying to use fulcro/forms. The form component has a parent that has some elements that needs to change based on the form's validity. Is there a recommended pattern for the parent to react to the form validation changes?


@azeem Just the pattern that React defines: callbacks. As your form changes, call a function passed from the parent through computed.


@tony.kay yes. But what is the recommended way to listen for form change for a form written with fulcro/forms. The form spec's on-form-change definition seems ideal. But this takes only a mutation.


Hello friends, I have a question that might have been asked several times. What is the fulcro story for React-native apps ?


If I look at the code I don’t see anything against it


@baptiste-from-paris As far I know (remember some discussions) it should work.


I’ve made it work for a simple app with om


@baptiste-from-paris I made trial once, not a lot, but I was able to get some initial setup working then


New episode, quite nice and fulcro is mentioned


@azeem Ah, sorry, I see your question. So, the mutation from on-form-change would be ideal. I spoke too soon because I didn’t think through exactly what you’re asking. Having that on-form-change mutation update specific data that is queried for in the parent would be the recommended approach, but it is missing a follow-on read (refresh) parameter that would allow you to specify that data outside of the form set has changed. I can open an issue to add that, but as a workaround you can add the f/form-root-key to the query of the parent and that will cause it to refresh.


Yes. Being able to specify follow on reads for on-form-change would be awesome!. I’ll try the f/form-root-key workaround for now. Thanks!


if you really want the callback lambda, then use React lifecycle (componentDidUpdate) to compare the next and prior props, and call the callback when you see the transition you’re interested in.


@azeem 1.1.0-SNAPSHOT just pushed to clojars. Has new support for refresh on form change, also params. See develop commit


Awesome!! will check it out


As a general note to the channel: I’ve not had time yet to refine the forms support. I know it does much of what I’d like to see it do, but it is the least baked feature of the library. The forms support is meant to encapsulate the following commonly needed pattern: keeping track of the “original” vs the “changes in progress” and make it easy to find and submit the delta to the server. It has a number of other hooks that are intended to make it work as a general purpose solution, but there is nothing special about it beyond this delta tracking. It really is just some code that makes a copy of what you declare, and can then diff it later. If you want to do something super fancy with a form, you can certainly just hand-code that. For example, if you wanted to send off changes to fields as they are made (e.g. onBlur), then the forms support is completely unnecessary for your app. Well, I guess the validation, field rendering, and other niceties *are* nice to have 😉 I’m happy to expand it as you find holes…so please point them out as you find them 🙂


damn, sending money via patreon is subject to a 22% VAT