4 ms·

> How would you know which way of writing React will be less painful, or what questions you need to ask yourself regarding the architecture of your app? Without

> How would you know which way of writing React will be less painful, or what questions you need to ask yourself regarding the architecture of your app? Without keeping track of what's going on in the community, how will you make informed decisions. Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM. Note that the React docs won’t teach you this. They’ll tell you about Enzyme but they won’t tell you how to make React more of an implementation detail and less of a “framework” that your entire application is tightly coupled too.

azangru 8y ago
> Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM. The question is, should the logic be in the central core of the application, or should it be spread around among the components? The concentric structure of a cleanly architected app will suggest that the app logic should be centralized, while the framework should just be an implementation detail. However, centralizing and abstracting away the logic makes for code that is 1) harder to delete; 2) harder to code-split.
- zachrose 8y ago
  > The question is, should the logic be in the central core of the application, or should it be spread around among the components? There are probably many such questions and at this point we’re trying to solve a problem that may not exist in an application we know nothing about. However, with test coverage (and maybe also type annotations) you can delete or move that code around with greater confidence, which means your decision doesn’t have to be as hard or permanent.
ng12 8y ago
> Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM. This is the point of React. It's why it was released hand-in-hand with Flux and later Redux. If you're not doing this, you're architecting your code poorly and no framework can save you.
- azangru 8y ago
  Notice how the community has been trying to move away from the centralized Redux though? Trying to co-locate inside single components presentation logic and the data needed to render this component? I am not saying it's necessarily a good thing, but it is... interesting.

azangru 8y ago

> Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM. The question is, should the logic be in the central core of the application, or should it be spread around among the components? The concentric structure of a cleanly architected app will suggest that the app logic should be centralized, while the framework should just be an implementation detail. However, centralizing and abstracting away the logic makes for code that is 1) harder to delete; 2) harder to code-split.

zachrose 8y ago
> The question is, should the logic be in the central core of the application, or should it be spread around among the components? There are probably many such questions and at this point we’re trying to solve a problem that may not exist in an application we know nothing about. However, with test coverage (and maybe also type annotations) you can delete or move that code around with greater confidence, which means your decision doesn’t have to be as hard or permanent.

ng12 8y ago

> Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM. This is the point of React. It's why it was released hand-in-hand with Flux and later Redux. If you're not doing this, you're architecting your code poorly and no framework can save you.

azangru 8y ago
Notice how the community has been trying to move away from the centralized Redux though? Trying to co-locate inside single components presentation logic and the data needed to render this component? I am not saying it's necessarily a good thing, but it is... interesting.