In my opinion merging two ways of generating view is redundant. You have to work on two markups – one's in Twig, another in JSX. You would probably want different styling (either CSS Modules, Styled Components or something even different), different way of providing data (REST endpoints or GraphQL instead of MVC with Twig), most likely a separate bundling system. On top of that, you would require every front-end developer to be able to work with both Twig and React, which is not that common nowadays.
React is a library for building entire views. It's too big and complex for just "adding interactivity". For doing just that, use something smaller, or even better, JavaScript with no addons.
If you really want to use React to build views, ditch Twig and use Symfony as backend only.
Yes. What made me think differently was the description of the Limenius/react-bundle package:
limenius/react-bundle
Features include:
Prerender server-side React components for SEO, faster page loading, and users that have disabled JavaScript.
**Twig integration.**
Client-side render will take the server-side rendered DOM, recognize it, and take control over it without rendering again the component until needed.
Error and debug management for server and client side code.
Simple integration with Webpack.
If the whole point of React is to combine the markup organization together with the js organization, then what is the point of integrating it with Twig, which purpose is to do the markup separately? So, I understand what you are saying, but I am curious about what the Limenius team had in mind.
Thanks for your reply. I guess what I did not explain well is that I am looking for interoperability or open standard. In React, there is a coupling between UI components and logic components at the global organization level, which prevents taking one side without the other. This is a limitation for interoperability, as you pointed out in the case of Twig. You suggested that the content side (stateful component, etc.) can be done in vanilla js. Following this clue, I looked around and found this. But then, in my opinion, what we really want is an open standard to allow the use of this kind of tools with different templating systems that only focus on the static structure. Moreover, for me and others, interoperability is by definition a permanent aspect of a global architecture that relates systems, not only a quality temporarily useful during a gradual transition from one system to React, as in React's "interoperability".
And thanks again. This interaction is very valuable to me. Your replies were enlightening. It could be that an open standard at this level is hard to think and/or will be too restrictive. I guess that I am looking for an explicit opinion on this subject.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Dominic,
In my opinion merging two ways of generating view is redundant. You have to work on two markups – one's in Twig, another in JSX. You would probably want different styling (either CSS Modules, Styled Components or something even different), different way of providing data (REST endpoints or GraphQL instead of MVC with Twig), most likely a separate bundling system. On top of that, you would require every front-end developer to be able to work with both Twig and React, which is not that common nowadays.
React is a library for building entire views. It's too big and complex for just "adding interactivity". For doing just that, use something smaller, or even better, JavaScript with no addons.
If you really want to use React to build views, ditch Twig and use Symfony as backend only.
Yes. What made me think differently was the description of the Limenius/react-bundle package:
If the whole point of React is to combine the markup organization together with the js organization, then what is the point of integrating it with Twig, which purpose is to do the markup separately? So, I understand what you are saying, but I am curious about what the Limenius team had in mind.
Well, Dominic, the only way is to try and see :-)
Thanks for your reply. I guess what I did not explain well is that I am looking for interoperability or open standard. In React, there is a coupling between UI components and logic components at the global organization level, which prevents taking one side without the other. This is a limitation for interoperability, as you pointed out in the case of Twig. You suggested that the content side (stateful component, etc.) can be done in vanilla js. Following this clue, I looked around and found this. But then, in my opinion, what we really want is an open standard to allow the use of this kind of tools with different templating systems that only focus on the static structure. Moreover, for me and others, interoperability is by definition a permanent aspect of a global architecture that relates systems, not only a quality temporarily useful during a gradual transition from one system to React, as in React's "interoperability".
And thanks again. This interaction is very valuable to me. Your replies were enlightening. It could be that an open standard at this level is hard to think and/or will be too restrictive. I guess that I am looking for an explicit opinion on this subject.