Adding support for enums

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Jun 11 08:49:01 UTC 2018 

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 <kaizhu256 at 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
> kaizhu256 at gmail.com
>
>
>
> On 11 Jun 2018, at 3:50 AM, Nicolò Ribaudo <nicolo.ribaudo at 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 <kaizhu256 at 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
>> kaizhu256 at gmail.com
>>
>>
>>
>> On 10 Jun 2018, at 11:26 AM, Michael J. Ryan <tracker1 at gmail.com> wrote:
>>
>> Just use symbols for your action type
>>
>> On Sat, Jun 9, 2018, 14:21 Doug Wade <douglas.b.wade at 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 at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180611/aa2f80c9/attachment-0001.html>

More information about the es-discuss mailing list