Think in Interfaces, Not Implementation: Using React Context API for Better Code Design

[@rickvian]

React lacks of scalable architecture out from the box,based on your videos and article i think you can develop a react scaleable architecture blueprint and open source it sir, that would be cool 😎 (can it be called framework?)

[@karlmaddux6209]

I'm using this idea to initialize data models in a react context and I'm enjoying the separation between my business logic from the view logic. But now I sometimes need to trigger re-renders explicitly or make copies of the data object for setting state. Do you have any good strategies for getting pure javaScript business logic to trigger re-renders? I really enjoyed your article, 'Modularizing React Applications with Established UI Patterns.' I wish there was more content like this for web development.

[@icodeit.juntao]

Thanks @karlmaddux6209 for posting here. To make the React to re-render, generally you should consider to put the data in state and use a setter to update it. Like in the context provider, you pass in both the data and the setter, and down the tree use the setter to change the data, that would automatically trigger a re-render. I guess in most cases you might want to check if the re-render is necessary, although normally the re-render isn't a significant problem.

[@casull6447]

thank you for this video

[@icodeit.juntao]

My pleasure, mate! Glad it helps!

[@Joao-nn6gn]

In terms of architecture , what does it called this Payment class ? and whered does it belong ? Is it from domain layer? Even tough there's only logic releated to how I present the data or from a layer to give support to presentation like View-Model ?

[@icodeit.juntao]

Good question Joao. I assume you're saying the PaymentStrategy class (as the Payment itself is a React component that uses the strategy from context)? Yeah, it belongs to the domain layer. As you might have noticed, that class has nothing to do with UI. It's purely data and computing. In more complicated cases, you might need a View-Model (more like a thinner value object in DDD). So I would say a domain model has logic to do the calculation, and view-model is much simpler and only has getter functions (although, in many cases, you can merge them into one object).