Adding support for enums
Isiah Meadows
isiahmeadows at gmail.com
Mon Jun 11 22:41:36 UTC 2018
This was the kind of library helper I was alluding to in my email. It's
incredibly easy to introduce a zero-overhead library solution to this
problem.
To be quite honest, I'm not convinced we actually *need* enums in JS. I've
used design patterns enough that it in my experience is much more flexible
than enums, while in the degenerate case of enums, doesn't actually add any
lines of code, and it doesn't really decrease boilerplate on the user side.
Also, enums aren't common enough in idiomatic JS to really be useful - we
can technically use just about anything to discriminate types on, and our
dynamic typing avoids most of the issues that make things like sum types
and sealed/abstract classes pervasive in other languages.
-----
Isiah Meadows
me at isiahmeadows.com
www.isiahmeadows.com
On Mon, Jun 11, 2018 at 4:49 AM, Andrea Giammarchi <
andrea.giammarchi at 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 <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
>>
>>
>
> _______________________________________________
> 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/3f51717f/attachment-0001.html>
More information about the es-discuss
mailing list