3 ms·

I remember when I looked into React that I was basically writing HTML templates into javascript code. Are there ways around doing that now with React? Because I

by rtpg 12y ago

I remember when I looked into React that I was basically writing HTML templates into javascript code. Are there ways around doing that now with React? Because I find that to be a pretty big affront to separation of concerns

purpletoned 12y ago
Separation of concerns is different from separation of technologies. For more details, view Pete Hunt's excellent talk at http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-best-practices.html http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
malandrew 12y ago
You don't have to use JSX. You can use React.DOM directly or use react-hyperscript as a shorthand method for React.DOM Also pay attention to the new createFactory method which aims to make it easy to separate your changing HTML from the static HTML (which you would have previously used a templating library for) My recommendation is to not use JSX ever since it breaks a lot of your tooling. The first impression people get is that "Hey this makes my code easier to read", but that is only because JSX introduces the problem that it attempts to solve. Basically most HTML structures are 80% unchanging and 20% changing (the reason we use templates in the first place). React.DOM was a pain previously because you'd define a complicated HTML structure in Javascript, which isn't really any harder or more complex, but then you'd have all this code that was never changing distracting you from the code that was changing (i.e. your app behavior). JSX fixed this problem by turning all the static bits to html like templates do so it was visually easy to separate from your behavior code. This was the wrong solution because it's over engineered and breaks compatibility with a lot of things. createFactory essentially allows you to "partially apply" the static parts and get a function that only needs to deal with the dynamic parts (like compiled template functions but for virtual DOM) Anyways, check out the following links: https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript https://gist.github.com/sebmarkbage/d7bce729f38730399d28 https://gist.github.com/sebmarkbage/d7bce729f38730399d28
spion 12y ago
The question is whether those concerns need separating. I've come to believe that the price to pay for that "separation" is too big and ends up being a re-implementation of shared scope (see angular's $scope)
- kuni-toko-tachi 12y ago
  Likewise the price to pay is yet another template language. ReactJS uses JavaScript as its template language. No more exporting filters, weird looping and conditional constructs. Just use Javascript. It just makes sense.
lobster_johnson 12y ago
Having used React for a year now, I have long concluded that React doesn't violate any separation of concerns at all. React implements UI views and controllers. You write views that know how to render themselves, and then you write views that control them; the latter type of view fulfills the role of the classical MVC controller. For example, consider how Cocoa works. It's a classical MVC framework: You have a view controller, which mediates between data and views. The controller doesn't know how to render anything, but it listens to data modifications, and sends update commands to the views; it also listens to changes to views and propagates those changes to the data model. (You can also let Cocoa Bindings do it for you, for the most part.) In a single app, you typically end up with many such controllers, typically one per window, and controllers can reference each other to facilitate communication; also, there are often controllers that individually control just a single view, because it's easier to encapsulate reusable components that way. For example, if you need a text field that autocompletes, you could subclass NSTextField and build this special behaviour into the view itself, but it's cleaner to create a controller that can bind to any normal NSTextView. In React, you have the same distribution of controllers (some handling big, multi-view layouts, some targeting discrete views), but the controller actually takes part in the view hierarchy: A controller has views as its children. It may not even use DOM elements, but consist entirely of custom view components. And it does exactly the same stuff as a controller would. For example, it may contain this: <Form> <TextField label='Name' minLength={3} ref='nameField' value={this.state.name}/> <NumericField label='Age' min={0} ref='ageField' value={this.state.value}> </Form> In this example, TextField and NumericField would be generic view components, just like the standard Cocoa views; the controller wouldn't be doing anything view-related like working with the DOM, but it would mediate between the data model and the child views that it controls. This is very much like building out a form in Interface Builder and connecting the actual controls to variables using IBOutlets. In fact, I would argue that there is hardly any distinction at all. The difference is that the UI is declared in the controller. And why not? Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.) The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other. So you might as well just keep the view layout in the same file as the controller. Which is what React does.

by rtpg 12y ago

purpletoned 12y ago

Separation of concerns is different from separation of technologies. For more details, view Pete Hunt's excellent talk at http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-best-practices.html http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...

malandrew 12y ago

You don't have to use JSX. You can use React.DOM directly or use react-hyperscript as a shorthand method for React.DOM Also pay attention to the new createFactory method which aims to make it easy to separate your changing HTML from the static HTML (which you would have previously used a templating library for) My recommendation is to not use JSX ever since it breaks a lot of your tooling. The first impression people get is that "Hey this makes my code easier to read", but that is only because JSX introduces the problem that it attempts to solve. Basically most HTML structures are 80% unchanging and 20% changing (the reason we use templates in the first place). React.DOM was a pain previously because you'd define a complicated HTML structure in Javascript, which isn't really any harder or more complex, but then you'd have all this code that was never changing distracting you from the code that was changing (i.e. your app behavior). JSX fixed this problem by turning all the static bits to html like templates do so it was visually easy to separate from your behavior code. This was the wrong solution because it's over engineered and breaks compatibility with a lot of things. createFactory essentially allows you to "partially apply" the static parts and get a function that only needs to deal with the dynamic parts (like compiled template functions but for virtual DOM) Anyways, check out the following links: https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript https://gist.github.com/sebmarkbage/d7bce729f38730399d28 https://gist.github.com/sebmarkbage/d7bce729f38730399d28

spion 12y ago

The question is whether those concerns need separating. I've come to believe that the price to pay for that "separation" is too big and ends up being a re-implementation of shared scope (see angular's $scope)

kuni-toko-tachi 12y ago
Likewise the price to pay is yet another template language. ReactJS uses JavaScript as its template language. No more exporting filters, weird looping and conditional constructs. Just use Javascript. It just makes sense.

lobster_johnson 12y ago

Having used React for a year now, I have long concluded that React doesn't violate any separation of concerns at all. React implements UI views and controllers. You write views that know how to render themselves, and then you write views that control them; the latter type of view fulfills the role of the classical MVC controller. For example, consider how Cocoa works. It's a classical MVC framework: You have a view controller, which mediates between data and views. The controller doesn't know how to render anything, but it listens to data modifications, and sends update commands to the views; it also listens to changes to views and propagates those changes to the data model. (You can also let Cocoa Bindings do it for you, for the most part.) In a single app, you typically end up with many such controllers, typically one per window, and controllers can reference each other to facilitate communication; also, there are often controllers that individually control just a single view, because it's easier to encapsulate reusable components that way. For example, if you need a text field that autocompletes, you could subclass NSTextField and build this special behaviour into the view itself, but it's cleaner to create a controller that can bind to any normal NSTextView. In React, you have the same distribution of controllers (some handling big, multi-view layouts, some targeting discrete views), but the controller actually takes part in the view hierarchy: A controller has views as its children. It may not even use DOM elements, but consist entirely of custom view components. And it does exactly the same stuff as a controller would. For example, it may contain this: <Form> <TextField label='Name' minLength={3} ref='nameField' value={this.state.name}/> <NumericField label='Age' min={0} ref='ageField' value={this.state.value}> </Form> In this example, TextField and NumericField would be generic view components, just like the standard Cocoa views; the controller wouldn't be doing anything view-related like working with the DOM, but it would mediate between the data model and the child views that it controls. This is very much like building out a form in Interface Builder and connecting the actual controls to variables using IBOutlets. In fact, I would argue that there is hardly any distinction at all. The difference is that the UI is declared in the controller. And why not? Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.) The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other. So you might as well just keep the view layout in the same file as the controller. Which is what React does.