Hype Buster: Legend State

Is the fastest React State Library the right state library for you?

Hey Full Context Developer,

We need to talk about Legend State! It’s a trending new state library for React and React Native apps that might fundamentally change how React’s component lifecycle works by drastically simplifying it using fine-grained reactivity. This might become the single most significant evolution of the React ecosystem this year. (More about this towards the end.) (Also support for more frameworks is likely to come in the future.)

---

Intro to the newsletter: Hey I’m Joe 👋, senior frontend developer and this is a short, more focused issue of the High Impact Frontend series. The goal of the whole publication is to cut through the noise of non-stop frontend tech buzz and bring you only the most impactful news that can create outsized, positive impact and change what you work with, the way you do development or even the course of your career.

I use the Full Context approach, my way to identify and explain the level of impact a tool or a piece of information can make and the hype-value scoring system. My goal is to offer a complete picture of when, how and who can realize that impact so you can easily find the most valuable news for you. You can find more details about this in a dedicated post.

My absolutely top secret, hidden agenda behind all this is to teach developers how to connect the technical part of our work with its business and real-life outcomes, so I can help you to make better choices and create better software for everyone.

If you think this work is worth supporting please consider upgrading to a paying subscription. Your financial support would make it possible to put in even more effort and produce higher quality content. Thank you if you consider joining the core Full Context Developers’ team this way!

---

I’ve decided to write this post as soon as I learned about LS because it has some really cool and interesting properties that also has the potential to easily overhype the library. (Starting with its name, which is kind of cool, not gonna lie. And the fact that it gives you signals for 4 KBs which is another trendy topic nowadays.) To quote its own introduction from GitHub:

Legend-State is a super fast and powerful state library that enables fine-grained reactivity and easy automatic persistence

This lib is so performant it claims to be the fastest React state library out there. Furthermore it’s optimized for arrays to the level that it even beats vanilla JS on the "swap" and "replace all rows" tests in the de-facto krausest/js-framework-benchmark.

And damn, that’s quite something! However I want to focus on the utility of this library from the Full Context perspective. Let’s jump straight into that.

Is This Really Legen …Wait For It… dary?

As most of you following already know, my goal is to offer a well balanced view of the benefits of the technology in review. To do that, I use the CPU-DB impact factors. (Customer Experience, Productivity, Utilization, Direct Costs, Business Opportunities).

I want to provide you with that type of analysis for Legend State so you will be able to decide whether it will deliver legendary results for your use case or not.

As the web performance experts say: “Fast is cash” and Legend State is fast, so is it going to increase the revenue a lot?

That's the question every one of us is trying to figure out right now. If it will lead to the type of speed improvements that shave off 100s of milliseconds from your important performance metrics it will become a no-brainer for lots of projects. But will you really achieve that by introducing it? And even if yes, what’s the price you have to pay for it?

The Name is Important: A State Library

I really like that the author is honest about the goal and scope of the project by calling it a state library and not a state management solution. This is actually one of my biggest worries about adopting it. What you currently get are super optimized primitives to handle reactive state. But it doesn’t come with a baked-in, enforced pattern to manage that state application wide.

It’s a tradeoff with pros and cons. You can roll your own flavor of state management, but for large scale, long-term projects where consistency and maintainability are crucial this might not cut it. If you check out the docs you will find a section called Patterns that show you some possible styles of handling application state with it. Jack Harringon’s YouTube video covering it also shows some extra patterns in practice.

If you are looking to create a new open-source project this is also a great opportunity. I think there’s huge potential in a higher level library that actually enforces a single pattern of handling application state, built over Legend State. (Legend State Manager, or… Legendary State?)

The Issues

With LS you can just go and directly get and set state all across the app, however you will miss the benefits of the centralized handling of state transitions when taking that route. This pattern can easily lead to a lot of issues:

• Duplicating the logic of updating the same piece of state across different parts of the app.

• Duplicating the logic of accessing and deriving new state from the same pieces of base state aka selectors.

• Introducing subtle bugs or divergence each time you reimplement the same state manipulation.

• It lacks an easy way to find or modify code that works with the same part of the state on the same way.

• It also lacks the ability to clearly show the shape of the whole application state as it can be ad-hoc defined at places of usage.

• Similarly there’s no definitive place to look for the possible state transitions.

All of these can lead to a huge mess down the line. However there’s nothing stopping you from implementing guardrails and establishing conventions to prevent these issues yourself. What I want to emphasize is that you need to do it consciously without much official guidance.

The Radical Rethinking of the React Lifecycle

I can’t deep link to it, but there’s a paragraph in the lib’s intro post called: Replacing global state AND all of the React hooks. If you are a React dev, you need to check it out. When adopting Legend State you can drastically rethink and reduce the complexity of the React component lifecycle. That is literally mind blowing! Read the linked post for the exact details. In a nutshell, this lib will eliminate re-renders, so you don’t have to care about anything related to subsequent rendering, all you have to take care of is when the (observed) state of the component changes. However you will have the library provided tools for that. If you give it a thought that’s a massive shift in the mental model of what happens at React runtime and a massive simplification! I still don’t fully comprehend its implications but I will look into it further. Would you like me to follow up on that?

CPU-DB: The Full Context Perspective

• Customer Experience: Legend State is small, only 4kbs of JS payload so you can save some initial bundle size by using it instead of some larger state management package (looking at you Redux). Its state updates are crazy fast and it can even hack the React render lifecycle to speed up rendering performance even more. These are not by default impactful improvements so I would precisely measure and validate if the project can meaningfully benefit from the high rendering performance it can provide. Most applications working on the standard React way are actually fine perf wise. Or can be optimized with the built-in optimization tools just fine. I can totally get why any frontend dev can get super enthusiastic about huge performance improvements but please don’t jump ship without considering the ROI of any tech choice.
  ➡️ Potential Impact: System Category
  

• Productivity: If adopting Legend State can really reduce the complexity of working with React hooks by eliminating the need to think about useMemo, useCallback, useEffect or useState (as the linked article says) while also making most of the component lifecycle irrelevant, we can gain a meaningful productivity improvement. If it can save us from the effort of handling all the weird edge cases and potential issues stemming from them, that difference can actually add up to something noticeable. On the other hand, if you don’t enforce good patterns for managing application state, the issues mentioned can easily negate any productivity gains.
  ➡️ Potential Impact: Group Category
  

• Utilization: This is always affected by changes in productivity. When that's improved your utilization goes down, which results in extra capacity and the chance to get more done under the same time as earlier.
  ➡️ Potential Impact: Group Category
  

• Direct Costs: No direct costs are involved besides the bang for your engineering hours as productivity dips at the beginning of adoption and hopefully improves as time goes on. This is where I have to point out that early adoption of any technology can actually become really costly through the productivity killing unforeseen issues that only arise as a tool gets more widely adopted and used. That’s why my recommendation for non-trivial projects is to only choose Legend State now if you can validate its usefulness and viability and there’s capacity and budget to stick with the decision even if you find some weird use cases that take time and community effort to support properly. (For example: SSR is just being explored.)
  ➡️ Potential Impact: Organization Category
  

• Business Opportunities: Performance improvements in general has the effect of bringing a broader audience to your websites and it’s the same with Legend State. With faster sites, more and more people fall into the category where performance issues won’t make them exit the journey before they convert so the reach of the product will increase. Which is a classic example of gaining new business opportunities.
  ➡️ Potential Impact: Organization Category

Should You Use It?

I recently read about the Innovation Point Principle from Addy Osmany (ex core jQuery, now Head of Chrome Developer Experience @Google) in a LinkedIn post. I highly recommend taking his advice when thinking about adopting new and shiny tech including LS. The principle is super aligned with the Full Context perspective of our work and it’s coming from a huge industry expert. Can’t love it more. But back to the lib…

I personally would only go all in with Legend State on low-risk projects. That typically means, side projects, internal tooling, PoCs, or any application that won’t be developed by more than ~ 3 people for a long time.

However I believe this is a tool that has great potential and interesting benefits so I definitely recommend experimenting with it if you can!

That’s all I can say about Legend State right now, but I’m looking forward to exploring it further in the future if you are interested. Let me know!

🏆 Final Score 🏆

📊 16 Points: Hype 4 x Value 4

Personal Update

While writing this post last week, I was on vacation with my family but something very interesting happened on Tuesday that I want to share with you all! I’ve interviewed Hugo Jobling for the newsletter about his experience using Remix in production. Hugo is an early (paying) adopter of the framework and also my colleague at Tesco working as a Principal Frontend Engineer. I had a chat with him about his experience with the framework and how it helped him to deliver multiple projects (one live in more than 2000 Tesco stores). I will share the details and many more interesting ideas about frontend development from our conversation. It’s going to be super insightful! Really looking forward to delivering it to you all soon.

I also wanted to say huge thanks for all the new subscribers, the rate of signups is actually accelerating, there’s 151 of you already following. That’s super awesome and I’m doing my best to deliver you an ever improving, interesting and valuable newsletter. Let me know if I can do anything more to make that a reality for you!

See you in the next one Full Context Devs!

Best,
Joe @fullctxdev

➡️ Thank you for reading Full Context Development. If you liked this post feel free to share it and subscribe to the newsletter if you don’t want to miss future posts.