-
-
Notifications
You must be signed in to change notification settings - Fork 15.2k
Do we want to rename dispatch() and getState() before 1.0? #229
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
Comments
or a more explicit: |
I think |
I don't mind |
I don't want symmetry ( |
I like this Trojan horse idea. To me, Maybe
|
|
Even with a single reducer, in practice the same action is still being handled by many different sub-reducers. I think |
Clojure uses |
Is If we throw away the Flux association (which is misleading anyway b/c there is no dispatching under the hood) they sound equally generic to me. |
I can perform a task, or a symphony, or a lobotomy. Dispatch is much narrower. |
Transducers have type Step<X, Y> = (acc: X, val: Y) => X ...but still conceptually related |
I like Also |
Could be another way: |
I kinda think so, and I don't see what it gives us versus *EDIT: although come to think of it, in the programming sense too |
For context, here are the dictionary definitions (I just took the first entry from Google):
|
Do you need the
|
@mindjuice That looks like a direct reference to an object, whereas |
@acdlite Sorry, I have no idea what you mean by that! Can you elaborate? |
@mindjuice Sure :) redux.state.todos // wrong whereas redux.getState().todos |
I see what you mean, but did you miss the parentheses after
|
I just have a slight allergy to |
I think it's a good idea to stick to verbs for method names in JS. |
@mindjuice Yes I know, but in the JS world accessors usually have verbs in front of them, so it could be a source of confusion. @gaearon Do we want to consider |
I don't think you need a verb for a read-only accessor, but that's just my opinion. Either way, it won't stop me from using Redux! |
@acdlite I (almost) never use |
@acdlite Might as well consider it too. :-) Let's leave this open for a while and hear more suggestions. |
The job of a function is to return a value. If the function is named for the thing it returns, I think that's great. |
Late to the party but some thoughts from a user. How about: getShape() or just shape() -Nate |
@mindjuice I see your point, but it's nice to be able to look at a parameter, method name, variable name, etc. and know if it's a function without having to refer to documentation. |
@acdlite Perhaps mildly. I generally prefer verbosity too (which iOS dev in Objective-C encourages), but functional programming tends to prefer terseness. Anyway, like I said, it's a minor issue. I still prefer |
Look at underscore's API. Pretty darned FP I think you'd agree. The accessor methods for Arrays are things like Anyway, that's all I have to say on the matter. Just give it five minutes! :-) |
@mindjuice Underscore API is a set of utility methods. It's assumed from context that they have single word names which aren't always verbs. There is no similar context here. |
We dislike Although since send and dispatch are synonyms and clojure uses send I would opt for send because it's shorter and gets the point across pretty well. |
I think it's important to consider the context. this.props.send(increment()); feels like it assumes some kind of network thing unless you worked with a similar convention before (unlikely for JS devs). |
Speaking about context, this is a flux-like library so flux-like idioms could be used. I know it's good to appeal to people not coming from flux but we must also keep in mind those who started by reading through vanilla flux and then moved onto redux. The more these concepts map to each other the easier the transition will be. Also, are there really any better suggestions than what seems like kicking off a network thing? |
There's the existing names which might be best after all :-) |
@goatslacker That's true to a certain extent, but what I like about Redux is that it improves some things that Flux got fundamentally "wrong" (e.g., renaming Stores to Reducers and moving who owns the state), so sticking to Flux terms may not always make sense . If |
For the other hand |
I agree that |
How about |
+1 for |
When |
I'm not a fan of |
|
Also, |
I have a feeling this is slightly going off topic. If we take a step back and see what we have when we execute dispatch(anAction())
// or
dispatch(anActionAsync()) The action method simply returns a plain object, or a function. It doesn't perfom anything yet. You might as well pass an object directly to
So it's actually just calling functions. Something like So maybe we should start from that? I don't have any good names for that but maybe it will help? |
|
I'd keep the existing names. I think dispatch fits more than any of the proposed replacements for it. If there is concern over getState being confused with component state then I'd probably make it more verbose, like getStoreState, rather than introducing another term like getAtom, but I don't really like either alternative. |
I agree. Let's keep the existing names. |
Actually, I don't.
I would expect to be able to do It turns out that ES6 supports to access it uniformly because it provides class property getters and setters. Uniform Access Principle is embraced in FP without get/set prefixes. Hence, instead of
it could be
I think, it might open an opportunity to have getters in store object but access them in the same way in @connect without thinking if I get a state property via a getter function from a class instance or a property from a plain object. It might be helpful to implement Lenses in store because they would behave seamlessly with getting objects properties. |
It's cool that we try to use all the new cool features, but we should think about browser compatibility also. |
@emmenko that's only a problem if you strive for IE8 compat. |
Sure, although there are other like classes etc https://babeljs.io/docs/advanced/caveats/ Just saying we should consider this and set a minimal target. Would be cool also to run some e2e tests against different browsers (eg: saucelabs). |
@vladap This is exactly what I said above. :D |
Bikeshedding thread here.
As part of 1.0 we can do some breaking changes we won't be able to do after 1.0. This includes bikeshedding on names.
I wanted this library to be a functional programming trojan horse for Flux people, which I think it succeeded at. Before we reach 1.0, we are able to drop some of the Flux naming baggage and find better names for whatever it does.
We're already getting rid of dispatcher and renaming stores to reducers. Do
getState
anddispatch
still make sense?Traditionally
dispatch
was called this way because in Flux an action really is dispatched across multiple Stores. In Redux, however, functional composition means that there is only one root reducer at the top. Do we reallydispatch
?I've also heard some people are confused by
getState
as it sounds similar to React'ssetState
and seems to imply some connection to React. In fact, Redux has nothing to do with React.What if instead of
{ getState, dispatch, subscribe }
we had...{ read, perform, subscribe }
?Let's bikeshed.
The text was updated successfully, but these errors were encountered: