4 ms·

For sites that are content-heavy I've started wondering if it makes sense to have the content server-side rendered the old-fashioned way, and use multiple React

by llimos 6y ago

For sites that are content-heavy I've started wondering if it makes sense to have the content server-side rendered the old-fashioned way, and use multiple React roots for the parts of the page that need to be interactive. You can still use Redux etc. for managing app state globally (though not React context), and you get most of the gains of load time, and of using React where you need it. It seems everyone uses <body><div id="app-root"></div></body> but React is perfectly happy being scattered around the page. It's just a thought, I haven't tried it myself yet - has anyone else?

ncrmro 6y ago
This map is actually a wordpress plugin that loads locations from google sheets into a JS var that a react bundles loads. Client already had the rest of the site built in Wordpress so easier to just make a plug-in with a shortcode that loads the react bundle into a div. I and some other built while i was at Poetic in Houston, Tx. https://www.houstonfoodbank.org/find-help/agency-locator/ https://www.houstonfoodbank.org/find-help/agency-locator/
sovietmudkipz 6y ago
At my old company we did this approach for some of our pages. We were transitioning away from our old codebase page by page but rewriting the codebase took longer. New features were still desired so we built/repurposed react/redux components into what we called “hybrid” pages. It worked great for us!
renke1 6y ago
React Portals could also help here, allowing you to still use context and the like.
CaptArmchair 6y ago
Depends on your business case / use case and where you want to draw lines. A lot rides on which parts you perceive as being "application" and which parts aren't. For instance, you could build an e-commerce shop as an SPA, or you could target specific parts that process user interaction dynamically / fluidly - such as the checkout process, adding to a cart,... - and consider those as separate applications. There are also trade offs. Search and navigation, for instance. You could build an SPA for an entire search engine. But then you may end up doing heavy lifting, like dynamically managing URL state through routing components, which is something browsers already do themselves: the only gain being that you don't reload the entire page. So, the big question boils down to: what are you really trying to solve? A UI/UX problem? A performance problem? A maintenance problem? Something else? And who are the stakeholders, who's using the stuff you're gonna build? What are their intentions and motives? That's when you come, to a conclusion: there's no silver bullet. The architectural design you choose needs to be an informed choice above anything else. And it should be informed by your specific context rather then the affordances provided by the tools at your disposal. The hard part is sitting down and taking a bit of time up front to think and articulate an argument that, given your context, validates choosing a particular strategy. (Personally, I tend to sit back and stare at the ceiling with my notebook and a pencil, but that's just me.)
catbuttes 6y ago
We do exactly this within SharePoint. We have various react parts that look things up in the database - sometimes quite heavy queries for reporting. We have put together a small collection of fairly generic react apps that mean we can put one on a page, put in some config and have it displaying a report generated in SQL in about as long as it takes to write the SQL for the report. We have used this approach for generic SQL reports, SharePoint lists, imgage retrival and entry forms. Having the library of options to hand has meant we can confidently assemble a new (fairly complex) page much quicker than previously - and be confident that it will work as it is reusing known good components.
dsego 6y ago
Yes, a hybrid. Routing and initial rendering handled by a server-side MVC framework, like Laravel. And on each page you can have one or more micro SPA-s with a lightweight JS framework like Mithril or Preact. You can even send the initial payload as JSON in a special JS global variable inside a script tag.

by llimos 6y ago

ncrmro 6y ago

This map is actually a wordpress plugin that loads locations from google sheets into a JS var that a react bundles loads. Client already had the rest of the site built in Wordpress so easier to just make a plug-in with a shortcode that loads the react bundle into a div. I and some other built while i was at Poetic in Houston, Tx. https://www.houstonfoodbank.org/find-help/agency-locator/ https://www.houstonfoodbank.org/find-help/agency-locator/

sovietmudkipz 6y ago

At my old company we did this approach for some of our pages. We were transitioning away from our old codebase page by page but rewriting the codebase took longer. New features were still desired so we built/repurposed react/redux components into what we called “hybrid” pages. It worked great for us!

renke1 6y ago

React Portals could also help here, allowing you to still use context and the like.

CaptArmchair 6y ago

Depends on your business case / use case and where you want to draw lines. A lot rides on which parts you perceive as being "application" and which parts aren't. For instance, you could build an e-commerce shop as an SPA, or you could target specific parts that process user interaction dynamically / fluidly - such as the checkout process, adding to a cart,... - and consider those as separate applications. There are also trade offs. Search and navigation, for instance. You could build an SPA for an entire search engine. But then you may end up doing heavy lifting, like dynamically managing URL state through routing components, which is something browsers already do themselves: the only gain being that you don't reload the entire page. So, the big question boils down to: what are you really trying to solve? A UI/UX problem? A performance problem? A maintenance problem? Something else? And who are the stakeholders, who's using the stuff you're gonna build? What are their intentions and motives? That's when you come, to a conclusion: there's no silver bullet. The architectural design you choose needs to be an informed choice above anything else. And it should be informed by your specific context rather then the affordances provided by the tools at your disposal. The hard part is sitting down and taking a bit of time up front to think and articulate an argument that, given your context, validates choosing a particular strategy. (Personally, I tend to sit back and stare at the ceiling with my notebook and a pencil, but that's just me.)

catbuttes 6y ago

We do exactly this within SharePoint. We have various react parts that look things up in the database - sometimes quite heavy queries for reporting. We have put together a small collection of fairly generic react apps that mean we can put one on a page, put in some config and have it displaying a report generated in SQL in about as long as it takes to write the SQL for the report. We have used this approach for generic SQL reports, SharePoint lists, imgage retrival and entry forms. Having the library of options to hand has meant we can confidently assemble a new (fairly complex) page much quicker than previously - and be confident that it will work as it is reusing known good components.

dsego 6y ago

Yes, a hybrid. Routing and initial rendering handled by a server-side MVC framework, like Laravel. And on each page you can have one or more micro SPA-s with a lightweight JS framework like Mithril or Preact. You can even send the initial payload as JSON in a special JS global variable inside a script tag.