I am learning about React, while keeping in mind an integration with Twig (Symfony), but also an eventual porting to mobile apps. So, it's a lot of things in different directions to keep in mind. Some wrote that Twig and React are not made to be integrated, because they overlap too much. I feel it does not have to be the case. After all, Twig can generate any HTML page and React is flexible in the way it generates javascript and its made to be called from an HTML page. I feel the separation you propose is a step toward such an integration. A Twig component can rely on javascript (thus possibly on a React component) for reactive communication with the user. Does it makes sense? A related question, in React, is the view part also reactive or only the content is reactive? I bet they can be both reactive and that might be in conflict with Twig. I have not covered porting toward a mobile app. That makes the situation even more complex. My bet is that only the content/logic part can be reused in mobile app. If that is true, it's another good reason for the separation. I am learning and hopefully what I am writing, which are guesses, make sense.
that's a very interesting question. If you want to integrate React with Twig (or any other view, for that matter), it is possible, but with an asterisk: Your component (in Twig) should contain only raw data in attributes, not the actual markup. For example, something like
That one you could grab on the JS side (by looking for data-react-root attribute), parse the data-props attribute and use ReactDOM.render afterwards. This is a method you'd use in somewhat transition period between server-rendered views (from Twig, Jinja or whatever) to an SPA rendered purely by React. A quick and dirty example can be found here: codesandbox.io/s/gallant-matsumoto... (check public/index.html, that'd be your Twig, App.js would be any component(s) you have).
That being said, if you really want to have your views generated by backend, try Vue. It's a very powerful framework that is made with such things in mind.
I was not much thinking about server vs client side, but I admit it's an important question. We can hope that in some future, using isomorphic architecture as needed, the system would decide for us these implementation details. As you know, even Twig can be rendered client side: github.com/twigjs/twig.js/. No, I was more thinking in terms of the language seen by the developer, irrespective of where and how it is compiled/rendered. I like Twig as a way to generate HTML, but I see that React is good for interactivity. I like PHP server side, but not as a templating language (even though it was first created for that purpose). I am not so keen with the idea of a universal language for these different purposes. That's why I was looking at Twig and React integration. I understand that you see a mix of both as a transition phase only. I would like to understand better why you feel it must be a transition phase? Why it cannot be the permanent way to develop? What's wrong with that? I looked at the example that you linked. It illustrates the interaction between a view and react in a very simple way. I like it. But, in this simple case, as, I am sure, you know, the interaction was not really needed. It would have been much simpler to do every thing in a fixed view. This illustrates my point. I want to code as much as is convenient in Twig and only use React for what it does well.
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.
I am learning about React, while keeping in mind an integration with Twig (Symfony), but also an eventual porting to mobile apps. So, it's a lot of things in different directions to keep in mind. Some wrote that Twig and React are not made to be integrated, because they overlap too much. I feel it does not have to be the case. After all, Twig can generate any HTML page and React is flexible in the way it generates javascript and its made to be called from an HTML page. I feel the separation you propose is a step toward such an integration. A Twig component can rely on javascript (thus possibly on a React component) for reactive communication with the user. Does it makes sense? A related question, in React, is the view part also reactive or only the content is reactive? I bet they can be both reactive and that might be in conflict with Twig. I have not covered porting toward a mobile app. That makes the situation even more complex. My bet is that only the content/logic part can be reused in mobile app. If that is true, it's another good reason for the separation. I am learning and hopefully what I am writing, which are guesses, make sense.
Hey Maharishi,
that's a very interesting question. If you want to integrate React with Twig (or any other view, for that matter), it is possible, but with an asterisk: Your component (in Twig) should contain only raw data in attributes, not the actual markup. For example, something like
That one you could grab on the JS side (by looking for
data-react-rootattribute), parse thedata-propsattribute and useReactDOM.renderafterwards. This is a method you'd use in somewhat transition period between server-rendered views (from Twig, Jinja or whatever) to an SPA rendered purely by React. A quick and dirty example can be found here: codesandbox.io/s/gallant-matsumoto... (checkpublic/index.html, that'd be your Twig,App.jswould be any component(s) you have).That being said, if you really want to have your views generated by backend, try Vue. It's a very powerful framework that is made with such things in mind.
I was not much thinking about server vs client side, but I admit it's an important question. We can hope that in some future, using isomorphic architecture as needed, the system would decide for us these implementation details. As you know, even Twig can be rendered client side: github.com/twigjs/twig.js/. No, I was more thinking in terms of the language seen by the developer, irrespective of where and how it is compiled/rendered. I like Twig as a way to generate HTML, but I see that React is good for interactivity. I like PHP server side, but not as a templating language (even though it was first created for that purpose). I am not so keen with the idea of a universal language for these different purposes. That's why I was looking at Twig and React integration. I understand that you see a mix of both as a transition phase only. I would like to understand better why you feel it must be a transition phase? Why it cannot be the permanent way to develop? What's wrong with that? I looked at the example that you linked. It illustrates the interaction between a view and react in a very simple way. I like it. But, in this simple case, as, I am sure, you know, the interaction was not really needed. It would have been much simpler to do every thing in a fixed view. This illustrates my point. I want to code as much as is convenient in Twig and only use React for what it does well.
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.