Great presentation, Jesse! Even though I think the naming is a bit off. This is really about the pattern of using container components and presentational components to increase the separation of concerns, not much about NgRx specifically. You can easily replace the dispatching of events and selecting from store with , plain old "services" being one of them.
well ngrx should be used with that pattern too. (only containers should red/write) the store to avoid unpredictability. I saw too many "developers" dealing with the same fucking issues because those concepts are completely missing!
This is good reactive form modelling (nothing to do with NGRX...) Also I think that you don't need the banana in a box as you should be subscribing to the form value change at the top level no need to bubble up anything here (IMHO). Thank you for sharing never the less, the presentation of the smart dumb comps is spot-on.
Hi Brett, I hope this comment makes your way. I'm working with a normalized store myself (ngxs but never the less, very similar pattern). Any recommendations on implementing reactive forms with a normalized state? I select for and denormalize state at each level in my component tree (5 levels deep or so of children for the creating a rubric form). It seems like I need to take changes from my reactive form => update store => denormalize state again in component => patch form with changes. Does that sound about right?
Where was the ngrx here? I think you mean Rxjs? I have no idea why you used event emitters to send reactive form data back and forth between between components. There are form directives that handle that kind of stuff natively with no .valueChanges subscription.
Mark Goho formgroups as I could see are created inside item components so emitters are used to notify root container and probably calculate total amount for all form groups.
Mark Goho honestly I didn't have this case before and I am not defending output emmiter approach, just noticed that might be the case why he used it :)
what does form directives have to do with what he showed? you cant use form directives to send data OUTSIDE of the presentational component into the container
Yes, when you link the presentational component via @Input parent = parent: FormGroup and attach the necessary form directives to the inputs and use formControlName, those form elements will properly communicate outside of that component to the parent form.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
where's the code
Thanks for great and informative video.
can you please add reference to the source code?
thanks again
You guys rock! Thanks for sharing the talks individually
🙏
Great presentation, Jesse! Even though I think the naming is a bit off. This is really about the pattern of using container components and presentational components to increase the separation of concerns, not much about NgRx specifically. You can easily replace the dispatching of events and selecting from store with , plain old "services" being one of them.
well ngrx should be used with that pattern too. (only containers should red/write) the store to avoid unpredictability. I saw too many "developers" dealing with the same fucking issues because those concepts are completely missing!
I was hoping to hear more about defart values.
This is good reactive form modelling (nothing to do with NGRX...) Also I think that you don't need the banana in a box as you should be subscribing to the form value change at the top level no need to bubble up anything here (IMHO). Thank you for sharing never the less, the presentation of the smart dumb comps is spot-on.
Hi Brett, I hope this comment makes your way. I'm working with a normalized store myself (ngxs but never the less, very similar pattern). Any recommendations on implementing reactive forms with a normalized state? I select for and denormalize state at each level in my component tree (5 levels deep or so of children for the creating a rubric form). It seems like I need to take changes from my reactive form => update store => denormalize state again in component => patch form with changes. Does that sound about right?
Where was the ngrx here? I think you mean Rxjs? I have no idea why you used event emitters to send reactive form data back and forth between between components. There are form directives that handle that kind of stuff natively with no .valueChanges subscription.
Mark Goho formgroups as I could see are created inside item components so emitters are used to notify root container and probably calculate total amount for all form groups.
if you use the form directives properly, all form elements can communicate with each other with no use of event emitter
Mark Goho honestly I didn't have this case before and I am not defending output emmiter approach, just noticed that might be the case why he used it :)
what does form directives have to do with what he showed? you cant use form directives to send data OUTSIDE of the presentational component into the container
Yes, when you link the presentational component via @Input parent = parent: FormGroup and attach the necessary form directives to the inputs and use formControlName, those form elements will properly communicate outside of that component to the parent form.
Just googled and found the source code github.com/RMAngular/ngrx-complex-forms
there's no examples