Thanks Nikolo, that was exactly what I was looking for.
Best,
-D
On Mon, Jun 11, 2018, 1:49 AM Andrea Giammarchi <andrea.giammar...@gmail.com>
wrote:
> it seems to be trivial enough to implement in user-land though
>
> ```js
> class Enum {
> constructor(...names) {
> [].concat(...names).forEach(name => {
> this[name] = Symbol(name);
> });
> Object.freeze(this);
> }
> }
> ```
>
> then you can have:
>
> ```js
> const Actions = new Enum(
> 'LOADING_SPINNER',
> 'LOADING_SEARCH_RESULT'
> );
> ```
>
> or using an Array if you prefer, with eventually the ability to use an
> object to map keys to values, instead of using symbols.
>
>
> On Mon, Jun 11, 2018 at 9:37 AM, kai zhu <kaizhu...@gmail.com> wrote:
>
>> hi nicolo, reading-up 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
>> kaizhu...@gmail.com
>>
>>
>>
>> On 11 Jun 2018, at 3:50 AM, Nicolò Ribaudo <nicolo.riba...@gmail.com>
>> wrote:
>>
>> Have you seen 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 <kaizhu...@gmail.com> 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, 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
>>> kaizhu...@gmail.com
>>>
>>>
>>>
>>> On 10 Jun 2018, at 11:26 AM, Michael J. Ryan <track...@gmail.com> wrote:
>>>
>>> Just use symbols for your action type
>>>
>>> On Sat, Jun 9, 2018, 14:21 Doug Wade <douglas.b.w...@gmail.com> 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
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
