{"action":"created","issue":{"url":"https://api.github.com/repos/acdlite/flux-standard-action/issues/4","labels_url":"https://api.github.com/repos/acdlite/flux-standard-action/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/acdlite/flux-standard-action/issues/4/comments","events_url":"https://api.github.com/repos/acdlite/flux-standard-action/issues/4/events","html_url":"https://github.com/acdlite/flux-standard-action/issues/4","id":92909731,"number":4,"title":"Minimal cross-framework standard","user":{"login":"taion","id":3112159,"avatar_url":"https://avatars.githubusercontent.com/u/3112159?v=3","gravatar_id":"","url":"https://api.github.com/users/taion","html_url":"https://github.com/taion","followers_url":"https://api.github.com/users/taion/followers","following_url":"https://api.github.com/users/taion/following{/other_user}","gists_url":"https://api.github.com/users/taion/gists{/gist_id}","starred_url":"https://api.github.com/users/taion/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/taion/subscriptions","organizations_url":"https://api.github.com/users/taion/orgs","repos_url":"https://api.github.com/users/taion/repos","events_url":"https://api.github.com/users/taion/events{/privacy}","received_events_url":"https://api.github.com/users/taion/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-07-03T16:58:01Z","updated_at":"2015-07-03T17:38:06Z","closed_at":null,"body":"Continuation of our discussion from Reactiflux -\r\n\r\nI like what you're trying to do here, but I think what you have maps more closely to what you've built in Flummox than you intend, and doesn't do a good job of describing how other Flux frameworks behave, which limits its utility as a potential interop standard and makes the name not as descriptive as it could be.\r\n\r\nFor example, you specifically privilege `status`, while it's not at all standard for Flux frameworks to have a concept of action status as separate from the action itself - neither Alt nor Marty have specific concepts of success/failure actions and just have those treated as actions with different constants.\r\n\r\nAs I see it, there are really 3 types of data on an action -\r\n\r\n1. Type/constant: identifies the relevant handler for the action\r\n2. Payload: user-specified contents of the action\r\n3. Metadata: framework-level information regarding action\r\n\r\nI'd probably organize the spec rather like:\r\n\r\n```\r\n{\r\n  type,\r\n  payload,\r\n  metadata\r\n}\r\n```\r\n\r\nI'd specify:\r\n\r\n* `type`: Something potentially appropriate as an object key, either a name string, a mangled name/ID string, or an ES6 Symbol - this should be sufficient to uniquely set up handlers\r\n* `metadata`: Framework-specific values not generated directly by the user - these can be things like original name of the action (in case it was mangled to dedupe), semantic action status for frameworks that explicitly model this (again, most frameworks do not), or other logging/diagnostic flags, or things useful for middleware\r\n* `payload`: As close as possible to what the user directly specified\r\n\r\nI can see where you're going with specifying `status` as a special thing, but for my tastes, it's too opinionated. I understand that you feel that it makes sense to Flux frameworks to have semantic notions of action status, and I can see the arguments you've made in that regard, but it's not suitable to insert this as part of what aims to be a \"minimal, common standard\" when other frameworks often do not express or capture that notion in this way - and moreover when there exists a more generic abstraction (i.e. the `metadata`) that can capture similar framework peculiar things in a way that makes it clear where the potential interop barriers sit."},"comment":{"url":"https://api.github.com/repos/acdlite/flux-standard-action/issues/comments/118398473","html_url":"https://github.com/acdlite/flux-standard-action/issues/4#issuecomment-118398473","issue_url":"https://api.github.com/repos/acdlite/flux-standard-action/issues/4","id":118398473,"user":{"login":"acdlite","id":3624098,"avatar_url":"https://avatars.githubusercontent.com/u/3624098?v=3","gravatar_id":"","url":"https://api.github.com/users/acdlite","html_url":"https://github.com/acdlite","followers_url":"https://api.github.com/users/acdlite/followers","following_url":"https://api.github.com/users/acdlite/following{/other_user}","gists_url":"https://api.github.com/users/acdlite/gists{/gist_id}","starred_url":"https://api.github.com/users/acdlite/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/acdlite/subscriptions","organizations_url":"https://api.github.com/users/acdlite/orgs","repos_url":"https://api.github.com/users/acdlite/repos","events_url":"https://api.github.com/users/acdlite/events{/privacy}","received_events_url":"https://api.github.com/users/acdlite/received_events","type":"User","site_admin":false},"created_at":"2015-07-03T17:38:06Z","updated_at":"2015-07-03T17:38:06Z","body":"> outside of e.g. Flummox and Redux, it's not something special or with semantic meaning\r\n\r\nNot currently, but it should! Good standards encourage good ideas. Making failed actions (actions that represents errors) a first-class concept is important, for the reasons described in my comment above. Suggestions for alternatives are totally welcome, but omitting it completely is not an option.\r\n\r\nI'm thinking we should replace `status` with a boolean `error` property (as I believe @clearjs suggested) to make it clearer what its purpose is. Also cleaner, since there are only two valid values anyway."}}