hi nicolo, reading-up https://github.com/rbuckton/proposal-enum
<https://github.com/rbuckton/proposal-enum>, i'm guessing this would be the
enum-solution to doug's name-collision problem?
```js
/*
* enum-solution with action = { type: Actions.LOADING_SPINNER, ... }
*/
enum Actions {
LOADING_SPINNER,
LOADING_SEARCH_RESULT
}
...
switch (action.type) {
case Actions.LOADING_SPINNER:
...
break;
case Actions.LOADING_SEARCH_RESULT:
...
break;
}
```
the above may look nice and familiar to backend-java-developers, but for
javascript-frontend-developers trying to manage integration-level complexity,
it looks like needless extra-overhead when simpler, throwaway glue-code would
likely suffice:
```js
/*
* plain-string solution with action = { type: 'LOADING_SPINNER', … }
*/
switch (action.type) {
case 'LOADING_SPINNER':
...
break;
case 'LOADING_SEARCH_RESULT':
...
break;
}
```
kai zhu
[email protected]
> On 11 Jun 2018, at 3:50 AM, Nicolò Ribaudo <[email protected]> wrote:
>
> Have you seen https://github.com/rbuckton/proposal-enum
> <https://github.com/rbuckton/proposal-enum>? The champion is a TypeScript
> member, so he already had experienc with enums.
>
> On Sun, Jun 10, 2018 at 5:44 PM kai zhu <[email protected]
> <mailto:[email protected]>> wrote:
>> In Redux, there are actions, which are strings, that get passed to a
>> reducer, which mutates the states. My coworker and I inadvertently added
>> the same action name, "LOADING" on the same page, but in two different
>> files. This led to a bug when both my modal and his search results would be
>> loading at the same time, but since they were never both visible, we didn't
>> catch the bug.
>
> can you explain in code how either enum or symbols could solve your problem?
> reading up on how reducers work @
> https://redux.js.org/basics/reducers#handling-more-actions
> <https://redux.js.org/basics/reducers#handling-more-actions>, i'm guessing
> the problematic code looks like the following.
>
> ```js
> // module spinner.js
> var action = {
> type: 'LOADING',
> ...
> };
>
> // module search.js
> var action = {
> type: 'LOADING',
> ...
> };
>
> // module main.js
> switch (action.type) {
> case 'LOADING':
> // inadverdently run both
> // spinner-loading and
> // search-result-loading actions
> ...
> break;
> }
> ```
>
> its not obvious to me how enums/symbols could be use in a less-complicated
> solution, than simply renaming action.type in your case with more descriptive
> names that won’t collide (e.g. 'LOADING_SPINNER', ‘LOADING_SEARCH_RESULT').
>
> kai zhu
> [email protected] <mailto:[email protected]>
>
>
>
>> On 10 Jun 2018, at 11:26 AM, Michael J. Ryan <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Just use symbols for your action type
>>
>> On Sat, Jun 9, 2018, 14:21 Doug Wade <[email protected]
>> <mailto:[email protected]>> wrote:
>> Hello friends!
>>
>> I had a bug the other day on my team. We use redux <https://redux.js.org/>
>> to manage the state on our application <https://resumes.indeed.com/>, which
>> is maintained by a large team. In Redux, there are actions, which are
>> strings, that get passed to a reducer, which mutates the states. My
>> coworker and I inadvertently added the same action name, "LOADING" on the
>> same page, but in two different files. This led to a bug when both my modal
>> and his search results would be loading at the same time, but since they
>> were never both visible, we didn't catch the bug. My coworker refactored
>> his feature, and broke my feature, such that rather than displaying a
>> spinner, we went straight to an empty results page, even when there were
>> results.
>>
>> In other languages, like the language I use most at work, Java, we would
>> instead use a language construct called an enum
>> <https://en.wikipedia.org/wiki/Enumerated_type> in this situation so that
>> the two different sets of actions weren't equal to each other. I did some
>> research into some previous discussions on this
>> <https://esdiscuss.org/topic/enums> topic, and it seems like the discussion
>> has been broadly in favor of it. I also noted that enum is a reserved
>> keyword
>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Keywords>,
>> which indicates some intention to add enums to the language.
>>
>> As such, I've spent some time working on a proposal
>> <https://github.com/doug-wade/proposal-enum-definitions> for adding enums to
>> ECMAScript. It is very heavily based on the work by rauschma
>> <https://github.com/rauschma/enums/blob/master/enums.js>, stevekinney
>> <https://github.com/stevekinney/ecmascript-enumerations> and rwaldron
>> <https://github.com/rwaldron/proposal-enum-definitions>. I wasn't sure if I
>> was using all the right words when writing the proposal, so to help express
>> myself better, I also spent some time writing a babel plugin
>> <https://github.com/doug-wade/babel/tree/babel-plugin-proposal-enum> that
>> uses a polyfill <https://github.com/doug-wade/enum-polyfill> against which
>> I've written a small test suite
>> <https://github.com/doug-wade/enum-unit-tests> (if you would like to run
>> them, you'll need to link the polyfill and the babel plugin into the tests).
>> Please do not take these as any indication of "done-ness", I wrote them to
>> understand how I would expect an enum in javascript to behave, and am
>> willing and eager to make changes as I get suggestions. I do, however, feel
>> I have done as much as I can on my own, and would like help in considering
>> the proposal, especially whether it contains any footguns, undefined
>> behavior, or things that would be surprising to newer developers, and
>> helping me identify what work is to be done to make this a "real" proposal.
>>
>> All the best,
>> Doug Wade
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/es-discuss
>> <https://mail.mozilla.org/listinfo/es-discuss>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/es-discuss
>> <https://mail.mozilla.org/listinfo/es-discuss>
>
> _______________________________________________
> es-discuss mailing list
> [email protected] <mailto:[email protected]>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
