{"action":"closed","issue":{"url":"https://api.github.com/repos/facebook/flux/issues/203","labels_url":"https://api.github.com/repos/facebook/flux/issues/203/labels{/name}","comments_url":"https://api.github.com/repos/facebook/flux/issues/203/comments","events_url":"https://api.github.com/repos/facebook/flux/issues/203/events","html_url":"https://github.com/facebook/flux/issues/203","id":74729862,"number":203,"title":"Proposal:  Classes as identifiers","user":{"login":"L8D","id":2355315,"avatar_url":"https://avatars.githubusercontent.com/u/2355315?v=3","gravatar_id":"","url":"https://api.github.com/users/L8D","html_url":"https://github.com/L8D","followers_url":"https://api.github.com/users/L8D/followers","following_url":"https://api.github.com/users/L8D/following{/other_user}","gists_url":"https://api.github.com/users/L8D/gists{/gist_id}","starred_url":"https://api.github.com/users/L8D/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/L8D/subscriptions","organizations_url":"https://api.github.com/users/L8D/orgs","repos_url":"https://api.github.com/users/L8D/repos","events_url":"https://api.github.com/users/L8D/events{/privacy}","received_events_url":"https://api.github.com/users/L8D/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-05-09T18:26:31Z","updated_at":"2015-08-17T22:27:25Z","closed_at":"2015-08-17T22:27:25Z","body":"Taking inspiration from the mindset of Angular's di.js 2.0 library, I think there's a better way to handle actions and callback handlers. For the time being I'm probably going to create a spinoff library of Flux using these idioms.\r\n\r\nClasses (or really, their prototypes) are used as identifiers for the types of actions. Instead of using string constants and raw objects for payloads (and additional 'ActionCreators'), you would create a class for each action type which can store the payload on initialization, be used to identify the type and loses the need for helper functions (which could be put in the class anyways).\r\n\r\nFor example, instead of having code that looks like this:\r\n\r\n```js\r\n// constants.js\r\nvar constants = module.exports = keyMirror({\r\n  TODO_CREATE: null,\r\n  TODO_UPDATE_TEXT: null,\r\n  TODO_DESTROY: null,\r\n  // ...\r\n};\r\n\r\n// actions.js\r\nvar TodoActions = module.exports = {\r\n  create: function(text) {\r\n    AppDispatcher.dispatch({\r\n      actionType: TodoConstants.TODO_CREATE,\r\n      text: text\r\n    });\r\n  },\r\n\r\n  updateText: function(id, text) {\r\n    AppDispatcher.dispatch({\r\n      actionType: TodoConstants.TODO_UPDATE_TEXT,\r\n      id: id,\r\n      text: text\r\n    });\r\n  },\r\n\r\n  destroy: function(id) {\r\n    AppDispatcher.dispatch({\r\n      actionType: TodoConstants.TODO_DESTROY,\r\n      id: id\r\n    });\r\n  }\r\n};\r\n\r\n// some-where-else.js\r\n\r\nTodoActions.create('Do something');\r\n```\r\n\r\nYou could write it like so:\r\n\r\n```js\r\n// actions.js\r\nfunction CreateTodo(text) {\r\n  this.text = text;\r\n}\r\n\r\nfunction UpdateTodoText(id, text) {\r\n  this.id = id;\r\n  this.text = text;\r\n}\r\n\r\nfunction DestroyTodo(id) {\r\n  this.id = id;\r\n}\r\n\r\n// ...\r\n\r\nmodule.exports = {\r\n  CreateTodo: CreateTodo,\r\n  UpdateTodoText: UpdateTodoText,\r\n  DestroyTodo: DestroyTodo,\r\n  // ...\r\n};\r\n\r\n// some-where-else.js\r\n\r\nAppDispatcher.dispatch(new CreateTodo('Do something'));\r\n// alternatively\r\nAppDispatcher.dispatch(CreateTodo, 'Do something');\r\n```\r\n\r\nUsing classes not only cleans up the code and avoids duplication, but it means your payloads have classes where you can define helper methods and further avoid duplication in your stores.\r\n\r\nIn your stores, if you want to listen for an action, you import the class for that action, and simply use an `instanceof` check on the payload (which could be abstracted away in Fluxxor or what-have-you). With this, you can even create action hierarchies by having actions inherit from a base class for the domain of the action.\r\n\r\n~~In addition to that, it'd be nice to use store classes directly (instead of strings) to identify them in `waitFor` calls. This would require a bit of prototype magic and having extra parameters to track where a callback came from (which would be handled by fluxxor or what-have-you), but is certainly do-able, and puts us that much further away from magic strings (and keeps things more consistent with how actions would be handled).~~"}}