Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello 👋
This pull requests adds an example written with React.
I don't even know if you want to include other approaches and frameworks into your analysis, feel free to just close this if you don't. Mostly I thought it's an interesting perspective and I was curious myself how a React version would look like. So I spend a bit of time to create an equivalent React-based implementation. It renders the very same things, but because React has some different principles, the module boundaries and responsibilities are shifted a bit.
I really wanted to contribute to your examples, because particularly like that the focus of the code here is on rendering, which is what React was originally made for. This allows us to skip many parts which people commonly complain about that make React apps complex:
<MyApp />
instead ofReact.createElement(MyApp)
. But I think in this example it is not needed and would introduce more complexity.npm
. Here, we can get way with loading React fromunpkg.com
. I did not want to vendor it into the code to avoid licensing issues, also to keep the git repo small. It boils down to around 60 KB of external resources loaded (compressed) which amounts to around 140 KB (uncompressed) of extra JS to parse, so less efficient than jQuery.Of course in a larger production app you would probably need to solve all these issues eventually, and the added complexity would add more insights into a jQuery vs. React debate, however, the example would also need to be much larger and harder to keep comparable. There are plenty of projects that cater to a comparison like that, most notably TodoMVC.
Another thing to do differently in a production app are the things mentioned in #2 like using actual
<a>
tags instead of<span>
s for the clickable page numbers. But I decided to stick to how it is implemented in the original solution. It would certainly be not very hard to do those adjustments in React as well.One thing that comes "for free" with React's virtual DOM diffing approach is that the elements in the DOM stay the same. Compared to using
empty()
(jQuery) orinnerHTML
("ES6") this keeps things like DOM state and focus, and shifts some work from the browser to the library.A major architectural difference is how components handle their state and communicate with each other. To keep the code as "idiomatic React code", I used a React hook to save the current page number. This makes it impossible to access this state from other components written in e.g. jQuery or ES6, without further adjustments. However, with most React apps, the whole app would be written in React and the interoperability with other components or libraries need to be solved only for exceptional cases.
In case it helps with understanding, I also re-wrote the example to use JSX.
Same code but using JSX syntax
I am not in any way part of the React team, so this example can only reflect my own opinion on how an example like yours can be reflected with React code.