I normally do one of two things:
1. Do `Object.freeze({...})`, where the object keys point to the values in
question.
2. Define the variants as constants with a descriptive prefix.
Both of these forms could in theory be inlined by engines (no clue why they
still opt to *load* them). But as it stands, I basically learned how to
work around the lack of enums in a way effective enough I lost the need for
them.
You could use numbers (what I usually use - my enums don't typically mix
with other enums), strings, or symbols (best for you). There's pros and
cons to each:
- Numbers are the most efficient of all of these, they are serializable,
and you can retain order. However, adding variants is a bit harder, and
debugging is a bit harder.
- Strings are the simplest, the easiest to debug, and are serializable, but
they don't retain order, and they are the slowest.
- Symbols are the most extensible (you don't need to be careful to avoid
duplicates), can be intermixed with other symbols, and are also fairly easy
to debug (almost on par with strings) if you label them with their names.
They don't retain order, and they aren't serializable.
If you *really* want sugar, you could easily define a function that creates
the variants for you, but I eventually stopped doing it because I found it
wasn't actually saving me any lines of code without hindering readability.
Also, because each of these have their strengths, I have found myself using
them in different scenarios:
- Numbers are my default. They also let me pack other info alongside them
(like flags), which make them more attractive for me.
- Strings are nice for prototyping. You can readily inspect and modify them
freely without even having to change the source code.
- Symbols are best when you have to worry about types getting otherwise
ambiguously mixed together within a single channel. I don't frequently find
myself in this situation, but I do on occasion.
Or, in summary, as much as I like the idea of explicit language enums, they
don't seem necessary to me anymore in JS at least.
On Sat, Jun 9, 2018, 17: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
