(no title)
mtc010170 | 4 years ago
First of all - thank you for all the hard work! My team and I are really impressed with what you've built so far.
The company I work for has recently started to adopt RTK and RTKQ. We're working in a legacy React/Redux codebase, and have been evaluating them as core libraries moving forward as we build one of our new features.
One of our other engineers has been leading the charge with learning/applying RTK/RTKQ.. so he has a better feel for it at this point, but I've been following along fairly closely in PRs.. and as the technical lead on our team, I'm responsible for deciding whether or not it's a good fit for us.
As of just a week or so ago, we've pretty much decided to go all in on it.. despite my initial reservations mostly due to worrying that it's just the latest "new kid on the block"
The RTK part I bought into pretty quickly. Having seen a bunch of flavors of Redux code, I especially love the way RTK allows you to write reducers that mutate state directly.. and just really abstracts away a lot of the complexity, providing a means to writing idiomatic Redux code! On the flip side, I am a little worried about how much it hides what Redux really does, as someone who took a while to really understand it myself. It's started to get into Rails territory from a magic standpoint ;)
RTKQ was a bigger leap for me.. my initial impression was that the API seemed a little clunky.. especially the query "builders" part. While I like the way it allows you to inject different API endpoints where they're used, I do fear it will result in some very tight coupling between it and the requests to services. Having said that, the API has grown on me since I first saw it. So maybe it's just a matter of familiarity.
Anyways, there's certainly more feedback I have! And I'd also be the first to admit I'm not totally fluent in all these libraries and concepts.. so not even sure I'm qualified to speak to these things or if this is what you're looking for. But feel free to reach out to me at bcooke@superdraft.io. Would love some feedback in ensuring our team is really using these libraries effectively.
Thanks again for all your hard work!
acemarke|4 years ago
Appreciate the vote of confidence. To maybe help address your concerns a bit:
I totally agree that RTK itself is a layer of abstraction that does hide _some_ of what you're used to with writing Redux code by hand. In fact, that's the explicit purpose of RTK in the first place :) At the same time, none of the Redux core concepts change. There's still a single store, you're dispatching actions to describe "events that happened", using reducers that produce immutably updated new state values, and using middleware like thunks to run async logic. The goal of RTK is that you're writing less code to do that :) I talked about some of the design history and goals in my "RTK 1.0" announcement post [0]
Probably the biggest common concern is that using Immer for writing immutable updates with mutating syntax is too much "magic". I get that concern, especially because you do _need_ to know that immutability is a critical part of Redux even with RTK. The best answer I have for that is education, which is why I plastered "IMMUTABILITY IS CRITICAL THIS ONLY WORKS BECAUSE OF IMMER" warnings all over our Redux docs tutorials [1], and have a usage guide page specifically on working with Immer [2].
Beyond that, almost all of RTK itself directly maps to Redux usage patterns that existed long before we created RTK [3].
RTK Query is definitely a much larger leap of abstraction. You're no longer thinking in "actions" and "reducers" and "thunks", but rather "endpoints" and "cache lifetimes" and "invalidation". I covered some of this mindset shift in a new RTK Query section of the "Redux Essentials" tutorial [4]. But, even here, RTKQ's React API was directly inspired from other libs like React Query, Apollo, Urql, and SWR. The "API slice / endpoint builder" concept is unique, and I agree those can get a bit lengthy, but there's definitely a lot of useful properties that come out of defining those up front. But, under the hood, it's all still typical Redux logic: dispatching thunks to make requests, a reducer to manage the cache state, plus a custom middleware to manage cache lifetime behavior. Certainly some bits of "clever" code in there (Lenz Weber is a genius!), but no real "magic" per se.
I'd suggest going through those new RTKQ tutorial pages and see if that helps get you more familiar with how it works. For that matter, the "Essentials" and "Fundamentals" tutorials we added last year may also help clarify just what RTK is doing for you as well.
If you'd like to chat more, I and the other Redux maintainers normally hang out in the #redux channel in the Reactiflux Discord [5]. Please come on by and ask questions!
[0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...
[1] https://redux.js.org/tutorials/essentials/part-2-app-structu...
[2] https://redux-toolkit.js.org/usage/immer-reducers
[3] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
[4] https://redux.js.org/tutorials/essentials/part-7-rtk-query-b...
[5] https://www.reactiflux.com