21–30 of 279 posts
I wish there were more details about this. Implementing a small scheduler seems like a monumental task and I'd love to learn more about how to implement a base-case.
> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…
"They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"
> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…
The only case I have is I love to use D3 for vis. But the thing is it's trivial to embed D3 into a react component and either let react handle rendering via svg or honestly just let D3 take over the DOM in that component. I do this all the time and it works very well.
Pros:
* I have generic "zoom/pan" implemented. I did this by making a generic ChartContainer with 5 zones - top, right, bottom, left, content - and you specify just the size of the non-content zones (if displaying them at all) and otherwise it behaves responsively (i.e. CSS style on the container is respected in the internal math). When you scroll the left/content/right vertically, or the top/content/bottom horizontally, it virtually scrolls the other components for you. It also of course handles the math, each area of the 5 is passed a DOMRect describing how big of SVG it can render
* I have smart edge routing component on a graph; if you are doing the math yourself on how to position the SVG elements, you can easily describe that graph, so smart edge routing is free
* my library has themes via CSS vars, and the components written in this way are obviously automatically themed
Cons:
* it's a bit verbose for sure, takes some small time and focus. After the initial investment in ChartContainer though, they work freaking awesome
* D3 graphs often come with sweet animations and such, I don't have any capability to emulate this today, I hate to do performance-heavy things like manually doing math every frame in a hooks-based way, and I don't want MobX in my component library
* you sort of lose access to the D3 ecosystem, nothing is free
To be honest, I think I have made a top-tier Gantt with the smart edge routing and zoom, my Graph looks sharp too, and for overhead views it's super nice to be able to zoom and pan and show rulers on the side (imagine showing factory layout, or a board layout, etc). Otherwise, if you are doing more traditional pretty eye-catching stuff, it's not quite meant for that approach
If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
The rendering part resonate with me. I've tried in some side projects SolidJS framework and I really enjoy that the rendering of each component occurs once! Easier to not fall into some traps that React has.
Honestly once you get used to it, it becomes second nature... For me at least.
One piece of advice I would give is to not try to ram the hooks use-case into things. It becomes especially annoying when you're dealing with asynchronous values, where you need to deal with 'null' and friends. Sometimes some imperative code in useEffect is simpler to read and easier to maintain; it's fine to step out of the paradigm for some things.
What does using Vanilla JS look like? Here's an example: https://github.com/wisercoder/eureka It uses two tiny 500-line libs. It uses TSX files, just like React. It has components, just like React. It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.
> Was this slightly more work than using a library from npm? > I'd definitely recommend using a library for this, and we settled on lit-html (link to library from npm) This article is mostly about switching from React to Lit. You can use modern web APIs (like FormData) with React, FormData's not a replacement for state management. You can use Web Components with React, the way Fluent UI does ( https://docs.microsoft.…
I kind of feel that given the "simplicity" of a single class wrapping custom elements, everything is pretty boring.
Note: I cannot do better.
Probably worth looking into again.
I also concur with the author about lit-html. It does one thing and does it really well, easy to understand, and no transpiling needed. Can't recommend it enough for generating dynamic html client side.
Aren't web components more of an addition to frameworks like Bootstrap than a React replacement?
So stuck with iframes which although I can hide to some extent, are terrible.
I promise you'll love it if you're switching from React (pure HTML, CSS, and JavaScript w/ minimal abstraction). And it's full-stack so no more stitching together frankenstacks. Good ol' isomorphic JS for devs who value their time/productivity.