Our great sponsors
-
-
reactjs.org
Discontinued The React documentation website [Moved to: https://github.com/reactjs/react.dev]
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
instantsearch
⚡️ Libraries for building performant and instant search experiences with Algolia. Compatible with JavaScript, TypeScript, React and Vue.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
searchkit
Search UI for Elasticsearch & Opensearch. Compatible with Algolia's Instantsearch and Autocomplete components. React & Vue support
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I imagine most of them could be, but this is an API which would require a lot of additional primitives, and end up duplicating a bunch of already-existing functionality for something which in the end would probably need to conform to the same rules hooks do, and with what certainly feel to me like clunkier ergonomics. You'd also still be left with the problems of class components like poor minifiability and unreliability for hot module replacement.
I have to go to bed, but if you'd like to see a much better explanation about why hooks were adopted, I highly recommend the [checks notes] 1,401 comment-long discussion[1] on the PR for adopting the hooks RFC back in 2018, as this sort of design was brought up frequently. Especially worthwhile is Sebastian Markbåge's ending summary about why the team was going with hooks[2].
Please don't hesitate to report things like janky scrolling to the issue tracker (https://github.com/reactjs/reactjs.org/issues). We were changing things a lot and I'm sure a bunch of regressions could've crept in, so all reports are super helpful.
I find this to be a very nice high-level explanation: https://medium.com/@ryardley/react-hooks-not-magic-just-arra...
In reality we use a linked list rather than an array. If you wanna dive into the code, I can give some pointers. For example, useState is implemented like this during first render (https://github.com/facebook/react/blob/87c803d1dad7e5fe88634...) and like this during next renders (https://github.com/facebook/react/blob/87c803d1dad7e5fe88634...).
However, _conceptually_ I'd recommend to think of Hook return values similar to "extra inputs" to your function, kind of like extra arguments. There are different ways to formalize it in different languages. We picked plain function calls for simplicity and low overhead, although you could imagine `yield` with generators or something like that.
> But Reagent supports functional components as well, with hooks and all.
I addressed this already: while reagent is able to emit function components, there is a performance penalty to this.[1]
> I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.
Hiccup is convenient to write, but it is a constant run-time cost and a significant storage cost given that you have to store long series of constructors to cljs.core.PersistentVector in your bundle, have the JS runtime actually construct the vector, then pass it through a Hiccup interpreter to finally produce DOM nodes and throw away the persistent vector, only to repeat this entire process again on re-render.[2]
> Helix has decided not to support that.
That is simply not true. From the Helix documentation[2],
> If you want to use libraries like sablono, hicada or even hx hiccup parser, you can easily add that by creating a custom macro.
These are all Hiccup interpreters you can readily use.
IME there is very little difference between using the $ macro in Helix and writing Hiccup. I do not really miss Hiccup when I use Helix, and you still have data as code ;)
While this is from an unrelated project, there are benchmarks[3] done against Reagent that demonstrate the sheer overhead it has. In practice it is not a big problem if you rarely trigger a re-render, but otherwise it is a non-trivial cost, and if you want to use modern React features (like Suspense), there is a lot of r/as-element mingling going on, converting cases, etc. that simply make Reagent feel more tedious to use than Helix.
Also, the newer UIx2, which largely borrows from Helix, is "3.2x faster than Reagent" according to one of the contributors.[4]
I think it'd be worthwhile to benchmark all of these libraries against each other and record the data in one place. Maybe I'll get around to doing it this weekend :)
---
[1] https://github.com/reagent-project/reagent/blob/master/doc/R...
[2] https://github.com/lilactown/helix/blob/master/docs/faq.md#w...
Nice! I think you might like it.
Ah yeah, that does take a while to unpack. I think a lot of the complexity there is dealing with a non-react library and the dynamic import(s). Binding non-react libraries can be a bit rough.
I do think it's a good example to show the big advantage of hooks, if you look at the use of the hook, super clean: https://github.com/graphql/graphiql/blob/50674292c55eadf0e61...
Great way to contain complexity and make usage really clean and simple!
I created this library that would allow you to put all your state logic into classes: https://github.com/baron816/use-structure
One example of this pattern is Searchkit [0] which performs most of its logic inside a singleton Searchkit class which is instantiated and passed as a prop to the root React component. A bonus is that it's easier to implement bindings for Angular, Svelte, etc. since they can rely mostly on the class. For example, it looks like Searchkit now suggests using InstantSearch (react-instantsearch-dom) [1] from Algolia, i.e. an entirely different maintainer, and it creates the bindings with a `Client(new SearchKit(...))` adapter [2] around the class (see the code on the home page at [0]).
[1] https://github.com/algolia/instantsearch
[2] https://github.com/searchkit/searchkit/blob/main/packages/se...
One example of this pattern is Searchkit [0] which performs most of its logic inside a singleton Searchkit class which is instantiated and passed as a prop to the root React component. A bonus is that it's easier to implement bindings for Angular, Svelte, etc. since they can rely mostly on the class. For example, it looks like Searchkit now suggests using InstantSearch (react-instantsearch-dom) [1] from Algolia, i.e. an entirely different maintainer, and it creates the bindings with a `Client(new SearchKit(...))` adapter [2] around the class (see the code on the home page at [0]).
[1] https://github.com/algolia/instantsearch
[2] https://github.com/searchkit/searchkit/blob/main/packages/se...
This is exactly what I'm doing with my personal "framework" I use for client contracts. It's just Web Components with a handy class based wrapper. I call it Template, since it's based off tags.
It's a joy to work in, feels "frameworky" but it's standard web standards with <100 lines of convenience JS wrapped around it. There is no magic beyond what the browser provides - I like I like it that way.
https://github.com/retrohacker/template/
It's "open source" as a reference. Just using it for myself. There aren't many docs beyond notes to myself. You're welcome to kick the tires. If you like it I'd entertain PRs and stuff but it's such a small library forking is probably entirely reasonable to make your own flavor too.
Cheers and happy hacking!
Take a look at Use hooks libraries for examples of code that you may want to have portability with (this is they typescript one because its the one I've used)
One of the simplest examples is "useToggle" which just sets a state variable to true or false. Not hard to write in a class component but it's still stuff that you may end up writing a lot.
A lot of similar ones are click and event handlers that need to be cleaned up after the component is unmounted.
useIsMounted is one I use a lot too to ensure I'm not trying to write state on an API callback once a component is unmounted.
You could add each of these to a class with an hoc and end up with withToggle(withIsMounted(withUseMediaEvent(MyComponent))) but that tends to be a bit of a mess.
> But Reagent supports functional components as well, with hooks and all.
I addressed this already: while reagent is able to emit function components, there is a performance penalty to this.[1]
> I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.
Hiccup is convenient to write, but it is a constant run-time cost and a significant storage cost given that you have to store long series of constructors to cljs.core.PersistentVector in your bundle, have the JS runtime actually construct the vector, then pass it through a Hiccup interpreter to finally produce DOM nodes and throw away the persistent vector, only to repeat this entire process again on re-render.[2]
> Helix has decided not to support that.
That is simply not true. From the Helix documentation[2],
> If you want to use libraries like sablono, hicada or even hx hiccup parser, you can easily add that by creating a custom macro.
These are all Hiccup interpreters you can readily use.
IME there is very little difference between using the $ macro in Helix and writing Hiccup. I do not really miss Hiccup when I use Helix, and you still have data as code ;)
While this is from an unrelated project, there are benchmarks[3] done against Reagent that demonstrate the sheer overhead it has. In practice it is not a big problem if you rarely trigger a re-render, but otherwise it is a non-trivial cost, and if you want to use modern React features (like Suspense), there is a lot of r/as-element mingling going on, converting cases, etc. that simply make Reagent feel more tedious to use than Helix.
Also, the newer UIx2, which largely borrows from Helix, is "3.2x faster than Reagent" according to one of the contributors.[4]
I think it'd be worthwhile to benchmark all of these libraries against each other and record the data in one place. Maybe I'll get around to doing it this weekend :)
---
[1] https://github.com/reagent-project/reagent/blob/master/doc/R...
[2] https://github.com/lilactown/helix/blob/master/docs/faq.md#w...
> But Reagent supports functional components as well, with hooks and all.
I addressed this already: while reagent is able to emit function components, there is a performance penalty to this.[1]
> I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.
Hiccup is convenient to write, but it is a constant run-time cost and a significant storage cost given that you have to store long series of constructors to cljs.core.PersistentVector in your bundle, have the JS runtime actually construct the vector, then pass it through a Hiccup interpreter to finally produce DOM nodes and throw away the persistent vector, only to repeat this entire process again on re-render.[2]
> Helix has decided not to support that.
That is simply not true. From the Helix documentation[2],
> If you want to use libraries like sablono, hicada or even hx hiccup parser, you can easily add that by creating a custom macro.
These are all Hiccup interpreters you can readily use.
IME there is very little difference between using the $ macro in Helix and writing Hiccup. I do not really miss Hiccup when I use Helix, and you still have data as code ;)
While this is from an unrelated project, there are benchmarks[3] done against Reagent that demonstrate the sheer overhead it has. In practice it is not a big problem if you rarely trigger a re-render, but otherwise it is a non-trivial cost, and if you want to use modern React features (like Suspense), there is a lot of r/as-element mingling going on, converting cases, etc. that simply make Reagent feel more tedious to use than Helix.
Also, the newer UIx2, which largely borrows from Helix, is "3.2x faster than Reagent" according to one of the contributors.[4]
I think it'd be worthwhile to benchmark all of these libraries against each other and record the data in one place. Maybe I'll get around to doing it this weekend :)
---
[1] https://github.com/reagent-project/reagent/blob/master/doc/R...
[2] https://github.com/lilactown/helix/blob/master/docs/faq.md#w...
> But Reagent supports functional components as well, with hooks and all.
I addressed this already: while reagent is able to emit function components, there is a performance penalty to this.[1]
> I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.
Hiccup is convenient to write, but it is a constant run-time cost and a significant storage cost given that you have to store long series of constructors to cljs.core.PersistentVector in your bundle, have the JS runtime actually construct the vector, then pass it through a Hiccup interpreter to finally produce DOM nodes and throw away the persistent vector, only to repeat this entire process again on re-render.[2]
> Helix has decided not to support that.
That is simply not true. From the Helix documentation[2],
> If you want to use libraries like sablono, hicada or even hx hiccup parser, you can easily add that by creating a custom macro.
These are all Hiccup interpreters you can readily use.
IME there is very little difference between using the $ macro in Helix and writing Hiccup. I do not really miss Hiccup when I use Helix, and you still have data as code ;)
While this is from an unrelated project, there are benchmarks[3] done against Reagent that demonstrate the sheer overhead it has. In practice it is not a big problem if you rarely trigger a re-render, but otherwise it is a non-trivial cost, and if you want to use modern React features (like Suspense), there is a lot of r/as-element mingling going on, converting cases, etc. that simply make Reagent feel more tedious to use than Helix.
Also, the newer UIx2, which largely borrows from Helix, is "3.2x faster than Reagent" according to one of the contributors.[4]
I think it'd be worthwhile to benchmark all of these libraries against each other and record the data in one place. Maybe I'll get around to doing it this weekend :)
---
[1] https://github.com/reagent-project/reagent/blob/master/doc/R...
[2] https://github.com/lilactown/helix/blob/master/docs/faq.md#w...
Everytime I try to understand how something in react works I actually look into how it's implemented in preact. Hooks is around 500 LOC. https://github.com/preactjs/preact/blob/master/hooks/src/ind...