-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Deprecating connectAdvanced #1236
Comments
👍 I could never understand what it does or why it was added. It sounds like if you need this kind of complexity you should just vendor the connect code and maintain it yourself. |
FWIW, the intended use case is for an end user to be able to customize how all the memoization and prop generation is handled, on their own. All the logic for managing the subscription itself stays the same - it's really just changing from calling If y'all are really dead set on removing it, we can, but I truly don't think it adds that much extra complexity. Lemme tag three folks who I know have a particular interest in this: @jimbolla, @epeli, @mariusandra. A couple of example usages: |
Bummed about this of course but I understand the reasoning and I can live with. Actually just realized I can achieve everything I want with the Farewell |
This would be a bummer. Kea is basically built around it. I'll need to see if I can work around it and will provide a more insightful reply next week, as I'm literally boarding a plane for a weekend getaway now. Cheers! |
I'm not using Redux so I don't have an opinion on this. |
Hey, after tinkering a bit with the code (read: totally rewriting Kea), I no longer need Now that I worked with the code again, I remember why I used it in the first place: I was being sneaky, grabbed the Now I bit the bullet and switched to just stealing the store from react-redux and using it directly to The rewrite comes with many other changes, some of which are breaking, so it's not released yet. However I got all the tests to pass, so it shouldn't be too long now. I still need to rearchitect the plugin system, integrate thunks and sagas and test it on my own app before I'm ready to release it into the wild. Thanks for the push guys! This rewrite was long overdue! |
Well, based on those responses, it sounds like the primary folks who were using it have determined that they no longer need it. I'd say that puts a nail in it. (I still don't think there's going to be much actual difference as far as the internal code goes, given the way things are structured, but we'll see.) |
Hi to all! `
` For my think, it's cleaner way to put some data from store\from view into Actions. Or mb i do something wrong? PS: and no need it more selectors func from reselect, so i do my self with equals of next props |
@flipmotion : would one of the other options for customizing |
@markerikson : I think it could be, but it’s, again, more useless code. In ‘connectAdvanced’ it better cuz ur get all props from state, from component it one place, and if u need just 2-3 things, it’s more simple. Again i create selectors for data in first call, then i can combine it in second calling with some storeProps and OwnProps. And the same with actionCreators like with computed data selection. And this do in one place, without cutting it for other functions in connect options.
I think it more boilerplate then connectAdvanced.
Like i in my previous post when i can put some data from store and ownProps in actionCreator in one simple way. I understand that this is a trick, but I am aware of my actions. I consider it a very simple and effective solution. Or i do something wrong? Thx. |
Connecting Deck.gl layers is very convenient with connectAdvanced. Layer classes can't be wrapped directly with connect because they are not React components. To create them you can leverage connectAdvanced's feature of getting dispatch and state in one function.
layers selector:
Such approach allows you to split layer creation to different files and keep each layer near to it's own selectors. I can't see how presented solution (or similar) may be achieved with mergeProps from connect. |
I would suggest that you add a deprecation note in the connectAdvanced's documentation, to prevent people, new to react-redux, from using it. |
Hello what is the final decision being made ? Is |
Oh, it's very deprecated now that the hooks API exists. |
Ok understood. Thanks. But will it actually be deleted from the code and connect used instead as timdorr was mentioning in his initial post ? |
No changes for the lifetime of the v7.x branch. When we finally get around to doing a version 8, we will definitely still have No concrete plans for a version 8, yet, but I expect that we'll tackle it once Suspense and Concurrent Mode are finally done and the |
Alright Mark, thanks for providing a detailed update.
This seems interesting. Any blog post and/or WIP branch where I can know more about this effort ? |
Just the React repo, really. I'm sure once CM/Suspense are truly "done" there will be a post on the React blog announcing that. |
oops my bad. Got confused. I thought React-Redux was doing some specific work for Suspense and concurrent mode support haha. |
And what about class components 😕 ? I didn't see any plans anywhere to expose such an API for class components. |
I'm not sure what you're asking here.
The React team is definitely not adding any new features to support class components. As for React-Redux, I'm not entirely sure if we'll be able to fully rework As I said, questions like this are best suited for the React repo, not here. |
yes yes sure. sorry about that. will try to find some other forum for that. I was asking because my app is using class components and connect API, as we are using Redux for state management . So was wondering if we would be able to use concurrent mode properly without big refactorings like changing components to hooks etc. I will wait for the concurrent mode to be "done" from the React team in that case to get a clearer answer. |
And this API is now gone as of v8.0.0-alpha.0! |
I intend to remove the
connectAdvanced
API from React Redux, essentially replacingconnect
with its contents.Why? It's an abstraction that we don't use ourselves, so it just becomes an indirection in the code. It is only minimally used in the community. It creates a more complex code base, which is a barrier to entry for many contributions. Plus, frankly, I just don't like it; it gives me Java flashbacks.
This is mainly to give the few folks that do use it a heads up. It won't go away until the next major release. However, I intend to add a deprecation warning at some point in the future. We'll do that after Hooks, just so we're not dropping two big changes in one minor release. Plus, you can lock to that version to have your Hooks and your connectAdvanced at the same time. Sound fair?
If there are specific use cases, we can see about migrating them into the
connect
API, most likely as options. This isn't about completely throwing away a big chunk of functionality, just simplifying the code base a bit and making it easier to grok for everyone.The text was updated successfully, but these errors were encountered: