Should I define model classes in React?

Question

React uses Flux architecture and it is said in https://reactjs.org/docs/thinking-in-react.html that React has two models - state and props. And there are some suggestions for model management in React https://reactjs.org/community/model-management.html - but all of this seems to some additional layers to enhance the Flux. The big questions to which I am seeking the answers are:

• Should I define model classes in React? I.e. if I have Customer class notion, then I can: 1) define the attributes of Customer directly as the attributes of state/props 2) define the attributes of Customer as the attributes of state.customer/props.customer; 3) define some JavaScript template/class Customer separately and simply say, that state.customer/props.customer is of type Customer and don't repeat attributes in the state/props. I feel, that 3) is the right approach, isn't it?
• If 3rd options (of the previous point) is the right approach, then how can I define the Customer template and how can I define that state.customer/props.customer is of this template? I could use those template in some serialization, some model validation tasks as well and I could use in ReactNative project as well.

Psilocybin

There are no rules for this, React purely focuses on UI - how you manage your app state is entirely up to you. – Hultin

If you dive in and start making something, you'll get a feel for how your data should be structured for your project. – Stabilize

@James, can you point me to some examples? React does not seem to focus purely on UI. If it did it it's docs and examples wouldn't all show storing the model in react state. – Parsons

@Parsons whilst React has mechanisms for holding state relative to a view, it is not strongly opinonated on how you manage your app state. It's a UI framework at the end of the day, and there are a few out there, so if you chose to couple your app state by holding it in views or using Context then that's a design decision that you make, and not one React forces on you. – Hultin

@James, all of the React docs use React's state, context, etc. If they were separate concerns then they'd be separate libraries. A UI library, and a separate state library. Clearly React does not focus purely on UI. If it did the state parts would not exist. Examples of how to separate the two would be way more useful the ambiguous statements that "it's possible" – Parsons

@Parsons redux.js.org/basics/reducers section "Note on Relationships" is very important design pattern: it says "We suggest that you keep your state as normalized as possible, without any nesting". From that I have deduced that there is little need for classes, especially - there is no need for graph of classes. E.g. if I have Invoice and InvoiceLine objects then I need to make 2 separate attributes on state: .invoice and .invoiceLines (array) and not the attribute .invoice with nested .invoice.invoiceLines properties. That is the way I understand this. – Psilocybin

@Parsons but the sentence "We suggest that you keep your state as normalized as possible, without any nesting" seems to be confusion: getting rid of entity relations and separating invoice from invoiceLines and avoiding nesting invoiceLines in invoice - all this is called "denormalization" in the database community. So - you can not do normalizing and not do nesting at the same time. So - if you have no references, no DB normalization, no graph of entities, but i you have only single objects (.invoice) and only arrays (.invoiceLines) directly as attributed of state, then there is no need for... – Psilocybin

@Parsons ...no need for classes. This is the conclusion from that reference from redux documentation. – Psilocybin

@Parsons Actually - this redux referencs is the sole advise that I was able to find. I am hunger for more, but there is nothing. I would be happy if you had any other references and if you wanted to share them. – Psilocybin

@Parsons don't take my word for it - React isn't an MVC framework. So again, as I said, React is a UI framework, and everything it offers is primarily geared around serving the UI. – Hultin

@Hultin As I understand, then Redux store is the most accepted approach for the MC of the MVC of React-based SAP. So - maybe we should discuss Redux specifically? Does it expect classes/graphs-of-classes as the attributes of state? Or just entities and arrays of entities and no relations between them? – Psilocybin

@Psilocybin since react-redux averages approx. 4m downloads per month, yeah I'd it's probably fair to say it's the most common state container for React :) (not to mention it was built by couple of guys from the React team). Redux doesn't care about the type of state you store, it is more about the functionality that surrounds it you are getting i.e. centralised, virw-agnostic state management with useful patterns / functionality. The state itself can be whatever you want, but to compliment React, it's highly recommended you make it immutable. – Hultin

@Psilocybin if you have any pointed questions about Redux and how to shape your data, setup a chat room :) – Hultin

Answer 1

The most basic way is shown in following snippet:

const Customer = ({ name, age }) => (
  <div>
    <p>Name: {name}</p>
    <p>Age: {age}</p>
  </div>
);

const App = () =>
  [{ name: "Bert", age: 22 }, { name: "Alfons", age: 45 }].map(
    ({ name, age }, i) => (
      <>
        <Customer key={i} name={name} age={age} />
        <hr />
      </>
    )
  );

Where you define these props depends on where you need them. If only one component needs the props, you define them in that components state. But often you need the props in several components, so you lift them in your hierarchy up. That often results in a very "smart" component (a component that has a large state).

If your app becomes large and confusing, I suggest you store your state externally. To do that, you can use react context. It allows you to inject props to components that need it, rather than passing it several layers down in your hierarchy.

If you don't want to write your own context, you may use state management solutions like redux or mobx. They use context too, but provide convenient functions to easily connect a component to your external state.

Cupulate