4 ms·
Implementing React from Scratch
- robpruzan 2y agoI started this project out of interest in building a UI framework for a completely different language/platform inspired by React. Quickly realized I didn’t understand everything React was doing to allow their API. Rebuilding React was extremely useful for learning more about the framework. Hopefully, this article is useful to other people in the same way.
- jinushaun 2y agoGood on ya. I gave a presentation a few years ago on building Promise from scratch and learned a lot in the process. I’ve always wanted to do the same for React.
- siamese_puff 2y agoYes, I love “from scratch” series as it follows the trend of Richard Feymans of I can’t do it I can’t understand it thing. Abramov has a good and old but relevant video series on Redux from scratch too.
- amelius 2y agoAt my work I try to build everything from scratch but my boss hates it.
- LoganDark 2y agoas he probably should. but building everything from scratch just is the autistic urge to actually understand what you're doing. not implying you're autistic or anything, but I am and I can't always stop myself from doing the same thing, hehe.
- KronisLV 2y agoAlso sometimes known as “not invented here syndrome”. Sometimes it’s useful to know how something works and to be easily able to change every piece of the stack, other times it’s a massive waste of time and the end result is a worse documented and worse developed solution than what hundreds if not thousands of people have built and tested over the years. Depends on what you’re working on, really, I’ve seen some really unfortunate stuff once people start rolling their own security stuff and it’s not like you can ask StackOverflow about why some random bespoke library or framework is full of weird behaviour. But for personal learning projects? Go wild!
- foobarbecue 2y agoWell yeah, don't USE your janky from-scratch libraries at work of there's something written & maintained by a bigger team. It's a learning exercise.
- siamese_puff 2y agoYah lol, agreed
- meiraleal 2y agoYour boss will hate it much more when the React-Tailwind-DaisyUI-datatable that imports 150 other npm packages becomes a massive security liability
- efortis 2y agoAbout React.createElement, implementing a compatible version ended up being my goto helper for small UIs. For example, I use it in mockaton here: https://github.com/ericfortis/mockaton/blob/7e6ad6226d7ed48e17897e5e66efe2fe2102ca49/src/Dashboard.js#L313 https://github.com/ericfortis/mockaton/blob/7e6ad6226d7ed48e... So if at some point I need React I can simply delete my version of createElement
- c-smile 2y agoJust in case: Sciter has Reactor - its own native and built-in implementation of React. Main difference is that component is instanceof Element - components are DOM elements. This allows to unify React and WebComponent under the same umbrella/mechanism. Yet to extend standard DOM methods by use of JSX, so this someDomElement.append(<div>Hello</div>) works just fine - appends content from the vDOM. In fact Reactor is three entities implemented natively: * JSX - embedded into JS compiler (830 LOC) - https://gitlab.com/c-smile/quickjspp/-/blob/master/quickjs-jsx.h https://gitlab.com/c-smile/quickjspp/-/blob/master/quickjs-j... , produces vDOM literals * Element.prototype.patch(JSX/vDOM) (420 LOC) - reconciliation / diff implementation * Binding of lifecycle methods (200 LOC) - componentDidMount and Co. There is also native implementation of Signal's (310 LOC) but they are optional for React'alike functionality.
- robpruzan 2y agoThis is very cool, first time I'm hearing of Reactor, thanks for sharing
- c-smile 2y agoCheck https://docs.sciter.com/docs/Reactor/ https://docs.sciter.com/docs/Reactor/
- solarkraft 2y agoThis is cool, but how big are the practical advantages (performance?)?
- eeue56 2y agoNice! I did a similar project, more focused on creating an Elm architecture framework in TypeScript here[1]). I based it on implementing virtual-dom logic for both Elm codebases and Derw's renderer. Since it's a decent amount of code, I couldn't find a good way to represent it in a blog post, and ended up making a commit-by-commit example on Github instead. Since it's FP-focused, it doesn't support useEffect/useState like this post, but rather has an external subscription/message system instead. It does support server-side-rendering, hydratation, and async events. It's a bit different in implementation in the OP's post, but I think the most important thing any reader should take away is that at the core, virtual-doms can be quite simple with plenty of room for further optimization. [1] - https://github.com/eeue56/make-your-own-tea/pull/1 https://github.com/eeue56/make-your-own-tea/pull/1