5 ms·
On the other hand, if you are not opposed to converting to React in the long run[0], but it looks too complex for merely adding some interactivity to a page: it
by strogonoff 7y ago
On the other hand, if you are not opposed to converting to React in the long run[0], but it looks too complex for merely adding some interactivity to a page: it can be simple to incorporate just a few widgets with it, a fact somewhat obscured by extensive documentation.
For a minimal start there’s no need to adopt JSX, wrap your head around hooks and functional components, or deal with Webpack configuration. Just add ReactDOM and React scripts, alias React.createElement() to something short like el() for use in render() methods, compose your components and render them at the desired root if user agent has JavaScript enabled[1].
You have the freedom to move the whole page to React later, implement server-side rendering and so on, but you don’t have to.
That said, yes, you will be pulling React, which will consume extra bandwidth, and to stay crawler-friendly your React components ideally should replace and improve functionality already provided by the static page in a more basic way.
[0] Perhaps you can see your application growing complex enough and you suspect React would be easy to hire for if you need additional help, etc.
[1] To preserve compatibility with older browsers but write components as modern classes, you could add a simple frontend build step that runs Babel on JS files with a single preset "@babel/env" specifying your target browsers.
- dragonwriter 7y ago> For a minimal start there’s no need to adopt JSX, wrap your head around hooks and functional components, or deal with Webpack configuration. Unless you've already learned React with class components and lifecycle methods, I suspect it simpler to just not learn them and learn functional components and hooks. It's extra stuff to wrap your head around if you learned the old way first, sure, but it's not fundamentally more complex on its own.
- strogonoff 7y agoI believe making proper sense of FCs and the seemingly arbitrary at first glance rules of hooks requires knowing the underpinnings of how hooks get called. In class-based components “didMount”, “willReceiveProps”, “willUnmount” et al. would be more or less intuitive to a newcomer with just a general idea of how it works. That I believe makes FCs fundamentally more complex to learn from scratch. Personally having some experience I go with FCs if there’s a new complex front-end project that is based on React, but I use class-based components if I need to sprinkle a few on a mostly static website that may have to be maintained by someone else. (Class-based components in a basic case, which would be the case in question, are also quite straightforward to convert to FCs.)
- Scarbutt 7y agoI suspect it simpler to just not learn them and learn functional components and hooks. The official react docs and tutorial don't help here since it introduces class components first.
- spankalee 7y agoIt's even easier to incorporate standard web components, because using them is as simple as using an HTML tag. If you have separate teams of engineers and designers/content creators, web components are a really nice interface that let's the engineers hide all of the implementation complexity for interactive components.
- strogonoff 7y agoI wish there was a single accepted standard for deploying native components. Last time I checked there were two competing implementations, JS modules (<script type="module" src="my-component.js">) and HTML imports (<link rel="import" href="my-component.html">, my personal favorite).
- spankalee 7y agoHTML Imports are not standard and have been removed from Chrome. <script type="module" src="my-component.js"> is indeed the single accepted standard.
- strogonoff 7y agoThe working draft was last updated in December 2019, unfortunate that browser support is so poor.
- spankalee 7y agoBrowser support isn't poor, it's just not a thing anymore. Chrome removing HTML Imports in _good_ so that we can move on to an agreed upon replacement that integrates with the JS module system like HTML Modules.
- deleted 7y ago[deleted]
- strogonoff 7y agoBack then I recall HTML modules being used as a synonym with HTML imports… It was contrasted with JS modules. Interesting. Anyway, the standard is there and apparently being worked on so I fail to see how it entirely isn’t a thing—hopefully another incarnation will land. All around it just feels like a solid way to bundle all the aspects of an element together.