Should I read this post?
I think that you are more likely to find value in reading this post if you are:
- Interested in my experience of learning from others; or
- Curious about the history of Redux-Leaves; or
- Made happy by expressions of gratitude to strangers on the internet.
A habit that I picked up during my academic studies is giving due credit to individuals who have been influential in shaping my thoughts, so I thought that it would be.
This occurred to me as I was preparing to give a couple of talks about an open-source library that I've written, Redux-Leaves.
Right now, I don't actually want to talk about myself or Redux-Leaves, but about how strangers on the internet who I have never met in real life made Redux-Leaves possible - not by contributing code to the repository, but by contributing ideas, blogs and talks to the public domain.
I think the time pressure in a talk would make it difficult for me to acknowledge those who have influenced my thought in a sufficiently eloquent or detailed way, and so I've decided to write up those thoughts in a blog post instead (and follow their example of putting things in the public domain!).
In no particular order, these individuals are are:
In some of these cases, I might be giving credit to an individual when it might actually be more appropriate to give it to a group of which said individual happens to be most prominent. This is not intentional and I apologise for people whom I have overlooked.
In writing this up, I've also realised that I'm missing out on a lot of learning by doing a VERY BAD JOB at finding diverse voices to learn from. So, selfishly, I'd love it if you would tweet me recommendations on individuals, newsletters or blogs to follow, particularly those more likely to have diverse viewpoints.
Without further ado, here's how each of those individuals contributed in some way to me writing Redux-Leaves.
Dan Abramov (@dan_abramov)
I'd like to credit Dan with three things:
- For planting the seed of my 'a-ha!' moment;
- For creating Redux; and
- For giving great talks generally.
Planting the seed of my 'a-ha!' moment
What I say below will make a lot more sense if you watch at least the one minute of footage where Dan introduces the React useState hook, although I recommend watching more of the talk (because it's great!).
The way that Dan introduced name and setName as a pair made me realise that a Redux store's reducer, and the actions dispatched to it, could be a pair returned from a single function. A reducer needs to be closely related to the actions dispatched to it.
This influence is clear when you compare the signatures for useState and reduxLeaves:
const [state, setState] = useState(initialValue)
const [reducer, actions] = reduxLeaves(initialState)
That 'a-ha!' moment for an API which gave you both reducer and actions - I didn't have any implementation specifics, just the high-level API desire - eventually led to the development of Redux-Leaves, which I'll write about in more technical detail another time.
Creating Redux
Another great talk given by Dan was the one where he introduced Redux (reducers + flux). Clearly, as a library which came out of my experiences with Redux, Redux-Leaves is also existentially indebted to Redux, although that might be obvious and non-interesting.
It might be worth noting that Redux-Leaves uses a cursor-ish approach, which Dan might not have intended for Redux, so he might regard me as doing something completely barbaric with Redux-Leaves. I won't put words in his mouth here, though, as I think Dan's opinions on Redux may have changed since he created it.
Giving great talks
If it wasn't obvious from the fact that I've linked to two of his talks, I think Dan does really great talks. I think that they have a nice theatricality that brings in the audience, and it also looks like he just really enjoys giving them, which itself makes them enjoyable to watch.
I think it's partly Dan's talks that have inspired me to start giving my own talks - which is why it's also great that Dan has written about how he prepares for his talks.
Mark Erikson (@acemarke)
I'd like to credit Mark with three things:
- An inspiring dedication to documentation;
- Remarkably thorough writings on and around Redux; and
- Maintaining Redux entirely outside his day job.
Dedication to documentation
Mark is seriously committed to good documentation. It's something that has inspired me with Redux-Leaves - I'm aiming to hit the same high bar of documentation. (I've even followed Mark in using Docusaurus.)
Writings on and around Redux
Mark has pulled together some really amazing writings on Redux - the two most significant being:
- Idiomatic Redux: The Tao of Redux, Part 1 - Implementation and Intent; and
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/.
It's certainly not necessary to read these before using Redux or Redux-Leaves, but I think if you're serious about deeply understanding Redux, it's highly advisable to read them.1 I can't strongly enough recommend Mark's posts for how well-written, researched and thought provoking they are.
Maintaining Redux
Mark also does a really heroic job of maintaining Redux - it's not his day job, he does it in his free time. I for one absolutely love the React-Redux hooks, released in v7.1.0, and rejoice in the prospect of never having to write another connect. Although the hooks seemed to appear like magic into my code with the update, an incredible amount of discussion and work went into them.
A big milestone recently was the official release of Redux Toolkit, which deserves to be looked at by all Redux developers. In particular, I'm a fan of its configureStore export as a big improvement on the API of createStore from the core Redux library.
Predictably, I personally prefer Redux-Leaves to createSlice, but I'd urge everybody to try out Redux Toolkit and see how they find it.
Kent C. Dodds (@kentcdodds)
Kent's writings on testing have made it significantly easier for me to refactor and publish updates to Redux-Leaves.
In particular, Kent brought two particular ideas to my attention:
The more your tests resemble the way your software is used, the more confidence they can give you.
What does this mean in practice?
Redux-Leaves as a library has very few unit tests, and quite a lot of integration tests, most of which are tests of documentation examples - i.e., tests that resemble the way the library is likely to be used.
The library has been through two refactors of note since I first wrote it. In the first refactor, I ended up dumping a lot of unit tests that were testing implementation and therefore completely wrecked by the refactor. I felt no qualms about this - the intended, documented use was covered by the integration tests, that were still passing after the refactor. In the second refactor, I don't remember having to rewrite or delete many tests at all, since the remaining tests were pretty much all about usage and not about implementation.
I now try to follow a process of 'Documentation-Driven Development' with Redux-Leaves. I start by writing the documentation for a new feature, and then I write tests for the documented usage that are agnostic about implementation, and then I start writing code. It's a marrying together of what Kent writes about testing with my dedication to documentation as inspired by Mark Erikson.
Shawn Wang (@swyx)
Shawn is famous for writing about learning in public.
I'm still trying to improve on this - for example, I sometimes worry about bothering people or looking like a shameless self-promoter, and Redux-Leaves has mostly been hacked together by myself, for myself - but I have nonetheless managed to gain some benefits from it. In the very early days of the library, I managed to get some really valuable feedback (with one particular signpost to Proxies leading to a major rewrite of the library).
This blog post itself is an example of me trying to be better at learning in public!
Tyler McGinnis (@tylermcginnis)
I subscribe to Tyler's weekly Javascript newsletter, which I like because it keeps a pipeline of cool projects coming into my inbox. I look at them, and I feel inspired to keep working on my own projects, the most major of which is - of course - Redux-Leaves!
What do I hope are the key takeaways from this?
Well, I'd like to think that this post helps encourage somebody to keep learning and working on their project, whether that be an open-source library like Redux-Leaves or something else.
The individuals I've cited all have pretty high-profiles, in that they all have at least 10k Twitter followers, so they certainly don't need me to promote them - but, even so, I think it's nice to thank people who've helped you, so I also would like to think that I've achieved that.
Finally, because I like the rule of three, I'll circle back to something I've alluded to earlier: I'm aware of an extreme lack of diversity in the figures I've cited here, which means that I'm missing out on a lot of learning. I want to fix this shortcoming. If you can think of anybody that I should follow, please tweet me a suggestion!
Endnotes
1 One thing that comes out of Mark's posts is that there are many technically valid ways to write Redux code, but not all of these might be intended ways to write it. For example, Redux-Leaves is a cursor-ish library that is more suited to modelling setters than events, which is technically valid - but this is not necessarily the way that Redux is intended to be used.
I had a short conversation with Mark about this, where he said: (a) "it's a legitimate approach from a technical standpoint, but not how we're trying to encourage people to think about things"; and (b) "if you've found a variation on a usage pattern that works well for you, go ahead and do that".
So, caveat emptor with Redux-Leaves, but I will write a separate covering my thoughts in more detail at some point. Acknowledging that Redux-Leaves might not be following an intended usage pattern for Redux, I still find that the benefits for me when I use it greatly outweigh the costs. MAIN
Top comments (0)