Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differences between RTK and Rematch #560

Closed
Izhaki opened this issue May 15, 2020 · 3 comments
Closed

Differences between RTK and Rematch #560

Izhaki opened this issue May 15, 2020 · 3 comments

Comments

@Izhaki
Copy link

Izhaki commented May 15, 2020

See twin issue on the Rematch repo: Differences between Rematch and Redux Toolkit (rtk)

I feel it is only appropriate to ask the same here.

Would be really useful for people to understand the pro/cons and philosophy behind each.

I've been over the moon with RTK, but now we're asked to migrate to Rematch and it's hard to make a case because neither frameworks mention the other in the docs.


This may not be a proper issue alright, because I'm not sure product comparison should be part of the docs.

But I'm sure those interested will stumble upon this issue.

@markerikson
Copy link
Collaborator

markerikson commented May 16, 2020

I don't think I need to "justify" this project's existence:

  • Anyone can create a package and publish it
  • I'm the lead maintainer of Redux, which certainly gives me reason to publish official Redux-related packages
  • I specifically created RTK to make it easier for people to use Redux
  • The incredibly positive feedback I've gotten and the continually-increasing download counts tell me RTK is indeed helping people

I'm happy to discuss differing tradeoffs and such, but I also don't see a need to spend time writing up comparisons with other tools in the docs, especially given that I have a ton of other docs work I'm currently trying to focus on.

(I will also note that Rematch does not have very much usage, overall, while Redux Toolkit's adoption is growing rapidly.)

But, if you'd like to know why it exists and what problems it's trying to solve, please see:

I will say, I'm curious: why are you being asked to migrate to Rematch, specifically?

@phryneas
Copy link
Member

I'm gonna jump on this and add two points:

  • RTK is just redux.
    You can take every single part out of RTK and use it side-by-side with any other redux-based library. RTK takes no shortcuts, modifications or assumptions over the redux core, but just offers a lot of helpers that help you get things along the way.
    There's no under-the-hood bootstrapping stuff that will break things if you use createSlice with the pure redux createStore instead of RTK's configureStore. (Yes, createAsyncThunk requires you to have the thunk middleware enabled, but that's about it)
    No auto-binding dispatchers that somehow mingles with what would be the job of a library like react-redux or reactive-react-redux.

  • RTK is not rematch. Also, it is not easy-peasy or one of the hundreds of other similar libraries that are out there. The purpose of RTK is to kind of contain that explosion of libraries, because if that would be going on with the speed it has in the past few years, you would never come from a project that was using rematch to another project using rematch.
    Every single redux-related project you'd be working on in your career would be using a different state mangagement abstraction that you'd have to re-learn, because there are just too many of them and there's no real consent on which to use.
    And, just like those two examples do, most of them are not really only helpers around the core redux, but they introduce completely new concepts that might directly conflict with concepts you were using in your last project, so coming from one to another might every time require you to unlearn old habits and even then send you into pitfalls that you were not aware to be library-specific.
    The only way around that explosion of libraries is one officially recommended library.
    Sure, there might be cases where it is really warranted to use one of the others, because of some kind of business requirement, but generally choosing one of them will steer you into a direction where you have to justify additional learning time for every future onboarded member of your team - for every single project. Personally, I'd say that "taste" or "one more fancy abstraction" is not one of them, especially as you can introduce those on top of RTK in your own code - while keeping the rest standard.

@Izhaki Izhaki changed the title Justification of this project in light of light of Rematch Differences between RTK and Rematch May 18, 2020
@Izhaki
Copy link
Author

Izhaki commented May 18, 2020

@markerikson That "justify" in the title is a copy-paste for the issue title in Rematch. Clearly neither need to justify anything.

What I really meant, and would like to establish, is the differences between the two in such way that someone can make an educated decision on why to pick that one or the other.

I also don't think you should be writing this. I was hoping for different people to chip in - like the (great) comment @phryneas left.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants