Typically, domain models and UI views are completely separated. A few years ago, we had a good reason to do so because the views were mostly made of imperative code. But now that we have functional UI libraries (e.g., with hooks), wouldn't it be possible to gather everything together, and implement the views as methods of the models they represent? React Object-Oriented Approach For example, let's say we have a class defined as follows: User { ({firstName, lastName}) { .firstName = firstName; .lastName = lastName; } getFullName() { ; } } class User constructor this this return ` ` ${ .firstName} this ${ .lastName} this Now, let's add a React component into this class: { View = { ; }; } class User // ... => () return {this.getFullName()} < > div </ > div And create an instance: user = User({ : , : }); const new firstName 'Arthur' lastName 'Rimbaud' Then, to render a for this , we can do: View user <user.View /> This is a perfectly valid JavaScript/JSX code, and I don't think there is something wrong with it. Conceptually, the method is no different than the method. They are just methods returning a different kind of view: returns a string and returns a React element. View() getFullName() getFullName() View() Functional Approach In a typical React app, we would not do so though. We would separate the view from the model like the following: { ; } ( ) function UserView {user} return {user.getFullName()} < > div </ > div Then, to render , we would do: UserView <UserView user={user} /> Does this more verbose approach bring benefits? No matter how much I scratch my head, I don't see any. The code is just more scattered. Decoupling It is always good to decouple the pieces of an application as much as possible. But does the functional approach (React components implemented separately as functions) brings more decoupling than the object-oriented approach (React components implemented as methods of a model)? It doesn't. Getting the models from a parameter or accessing them through makes no difference. In both cases, models and views become tightly coupled. this Separation of Concerns Some might argue that it is good to separate the model from the view because they are two different concerns. I don't get it. Again, how, in the object-oriented approach, the method is different than the method? Both are returning a representation of the model, so why should we separate them? getFullName() View() It remembers me of the discussion about separating HTML and CSS. Yes, they serve two different purposes. HTML describes the content and CSS describes the presentation. But I don't think there is something wrong about putting them together in a cohesive way. Sharing One Model with Multiple UIs Let's imagine we are building an app for several platforms: a web app (with ReactDOM) and an iOS app (with React Native). In this case, we usually want to share the same model with all platforms, and implement different UIs for each platform. To achieve that, we can implement the model separately and subclass it to implement the different views. Refactoring our previous example, we define the model in a separate file: User shared/user.js: { ({firstName, lastName}) { .firstName = firstName; .lastName = lastName; } getFullName() { ; } } export class User constructor this this return ` ` ${ .firstName} this ${ .lastName} this Then, we subclass it to implement the views of the web app: web/user.js: {User BaseUser} ; { View = { ; }; } import as from '../shared/user.js' class User extends BaseUser => () return {this.getFullName()} < > div </ > div And the same goes for the iOS app: ios/user.js: {User BaseUser} ; { View = { ; }; } import as from '../shared/user.js' class User extends BaseUser => () return {this.getFullName()} < > Text </ > Text , the code is then a bit more scattered, but , it is not. Whichever the platform, from a instance, we have access to both the model ( ) and its views ( ). Physically logically User user.firstName <user.View /> Composition over Inheritance « Inheritance is evil. » « Composition is the way to go. » I'm tired of hearing that all the time about anything and everything. Yes, single inheritance in static languages (Java, C#, etc.) may not be the right approach for composing the multiple pieces of an application. But it is not true with JavaScript where inheritance is dynamic, and therefore, extremely flexible. For example, we can use mixins to enable any kind of inheritance: multiple, conditional, parameterized, etc. There are many ways to implement mixins in JavaScript, but there is only one good way, and it is incredibly simple. Please for a nice explanation. head over here Conclusion I tried the object-oriented approach when implementing the with , and I think it worked pretty well. Encapsulating the views into the models made the code a lot more cohesive than if the views were implemented separately. RealWorld example Liaison If you are skeptical (you should be), please have a look at and tell me what you think. the code Since most of the models are implemented in the , the frontend models are pretty much just composed of views. backend Some might think that the classes are a bit crowded. I guess it is a matter of taste. Personally, as long as the content is related, I don't mind large files. If you prefer small files, you can group some views into mixins and assemble them into a single model. This article was originally published on the Liaison Blog .
