Constant objects

[kristian-puccio]

Just looking at the constants I'm not sure what the point of using objects to define constants.

Say for example I have { User: ['ADD', 'REMOVE'] } The constants I end up with are basically just 'ADD' and 'REMOVE' which means that I leave my self open to constant collisions if I don't namespace the actual constant key.

Would it make sense to include the 'Path' in the generated constant?
ie { User: ['ADD', 'REMOVE'] } would result in something like 'User__ADD' and 'User__REMOVE'.

You probably make this change without affecting anyones code as you always lookup the values of the constants from the constants list.

[taion]

How do you propose that work with the current API? If I call something like

var UserConstants = Marty.createConstants([
  "ADD_USER",
  "DELETE_USER",
  "UPDATE_USER_EMAIL"
]);

per the guide, how do I pull out that "User" string?

[kristian-puccio]

I think more I was meaning when you pass an object rather than an array to
the createConstants command.

var Constants = Marty.createConstants({
  Users: ['RECEIVE_USERS', 'DELETE_USER'],
  Foos: {
    Bars: ['ADD_BAR']
  }});

Which would result in:

{
   Users: ['Users__RECEIVE_USERS', 'Users__DELETE_USER'],
   Foos: {
       Bars: ['Users__Foos__ADD_BAR']
   }
}

The issue I am trying to avoid is this:

{
    Users: ['ADD'],
    Pages: ['ADD'],
}

Constants.Users.ADD and Constants.Pages.ADD would result in the same
constant and both trigger the same stores.

[kristian-puccio]

ugg sorry, I should have logged into github rather than replying to the email.

[taion]

It doesn't really save you much typing to write Constants.Users.ADD instead of e.g. Constants.ADD_USER, though.

[kristian-puccio]

I don't think it's about how much you have to type more about expect behaviour. I had to read the source to convince myself that the constant aren't being created with any sort of name spacing.

I'm not really sure what the point of passing a nested object to createConstants if they aren't name spaced. You could just use a flat array and do the name spacing yourself as you suggest.

[taion]

Oh, you mean actually passing in an object when you define constants? I misunderstood. I didn't realize that was supported. What you're saying makes sense, then.

[kristian-puccio]

Awesome! sorry if I was confusing.

[Deide]

If we needed to keep the current API, something like

function constants(ns, arr) {
let result = {},
      constantsList,
      namespace;

  if (typeof ns === "string") {
    constantsList = arr;
    namespace = ns;
  }
  else if (Array.isArray(ns)) {
    constantsList = ns;
    namespace = "";
  }
  else {
    throw new Error("The signature for creating constants is ([namespace:string, ] ConstantsList:Array)");
  }

  constantsList.forEach(function (item) {
    let types = [
      item,
      item + "_STARTING",
      item + "_DONE",
      item + "_FAILED"
    ];

    types.forEach(function (type) {
      result[type] = namespace + type;
    });
  });
  return result;
}

module.exports = constants;

would probably work out nicer.

[taion]

It's fine as far as it goes, but I think it'd rather move to constants being unique symbols - the problem is that it's technically a breaking change.

[kristian-puccio]

though constants are generated runtime and only exist until the browser is
refreshed so you might be able to get away with an update.

Otherwise you could add an opt-in flag maybe?

On 1 July 2015 at 12:59, Jimmy Jia [email protected] wrote:

It's fine as far as it goes, but I think it'd rather move to constants
being unique symbols - the problem is that it's technically a breaking
change.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[taion]

I meant just in case someone was actually taking advantage of how constants map to their string values. Not sure why you'd do this, but it could conceivably break someone.