redux-utilities / flux-standard-action Goto Github PK
View Code? Open in Web Editor NEWA human-friendly standard for Flux action objects.
License: MIT License
A human-friendly standard for Flux action objects.
License: MIT License
Properties payload
, error
, and meta
are all optional properties according to documentation. However I believe there are cases where actions may need to make these properties required ( such as actions based around a text search ). Adding interfaces such as those suggested by @dsanders1234 in a previous issue about these options not being correctly typed as optional strikes me as a good approach, and I'm thinking of doing something similar as a workaround. The standard FluxStandardAction
could remain in place while those additional versions could be used as needed.
Continuation of our discussion from Reactiflux -
I 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.
For 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.
As I see it, there are really 3 types of data on an action -
I'd probably organize the spec rather like:
{
type,
payload,
metadata
}
I'd specify:
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 handlersmetadata
: 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 middlewarepayload
: As close as possible to what the user directly specifiedI 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.
Hello,
I have isErrorAction
and isNotErrorAction
functions in my codebase and thought it would be nice to have them in the FSA package.
There is isFSA
function so these are nice additions to it.
My use cases are epics and reducers.
Should I create PR adding these?
function isErrorAction(action) {
return action.error;
}
function isNotErrorAction(action) {
return !isErrorAction(action);
}
With the thunk middleware, you get getState
as the second argument.
Do you have any suggestion on how I could use the current store state in my promise?
Currently I need this to get auth tokens for my API.
I wrote some types signatures for the redux-duck library. It creates FSA actions so I used the types from flux-standard-action
for those. Then I opened a pull request against DefinitelyTyped that is the de facto place for storing javascript library type signatures. However, it turns out that linking to types that are not part of the DefinitelyTyped repository is problematic. It seems they only do it for substantial libraries written in TypeScript. I'm now wondering if you are perhaps interested in migrating your index.d.ts
to DefinitelyTyped to make it's reuse easier.
What is the origin of a convention to call action name (e.g. ADD_NAME
, REMOVE_NAME
) a "type" (or "actionType" or "actionId")?
"actionId" is the most accurate of the suggested variations. However, what we are calling a "type" is actually a "name".
It is easy to see that "type" is wrong if you either lookup dictionary definition or try to replace it with either of the direct synonyms (e.g. kind, sort, variety).
as opposed to an instance of Error
object. Boolean flag is vague. It just says what the error is and does not standardise the method of getting error description. Docs say that payload
by convention should be an Error
object.
Using TypeScript and the included typings makes meta
a required property in a FSA.
import {FluxStandardAction as Action} from 'flux-standard-action'
public static updateYear(year: string): Action<string, null>
{
return {
type: Actions.SDS_VEHICLE_SELECTION_YEAR_UPDATE,
payload: year
}
}
This will complain that meta
does not exist in my action. Looking at the typings, I see that meta is no longer optional:
export interface FluxStandardAction<Payload, Meta> {
/** ... **/
meta: Meta; // Notice the lack of ?
}
Is this wanted behavior?
As defined in the readme, I think a strict reading says that two actions of the same type must be strictly equivalent, i.e.:
firstActionOfTypeA === secondActionOfTypeA
But my interpretation is that the intent is to say that the type
values must be strictly equivalent, not the two actions themselves, i.e.:
firstActionOfTypeA.type === secondActionOfTypeA.type
firstActionOfTypeA !== secondActionOfTypeA
If i'm both reading and interpreting correctly, I think the section might need rewording. So my question is, am I doing both of those things correctly? π
There's been a lot of confusion about status
and its purpose. You can read some of the reasoning behind it here: #4 (comment)
I propose we replace status
with a boolean error
field. If error
is true, then the action represents an error, and the payload should (by convention, like with rejected promises) be an error.
By request from #redux on reactiflux...
Admittedly this is pedantic, would you consider renaming body
to payload
? I thought the term payload
was used in Facebook's original Flux guides, but I didn't see it. So perhaps other implementations use payload
? I know that you had commented that Flummox uses body
. It probably doesn't matter much, but body
makes me think that I'm dealing with a web response.
Continuing from our conversation on slack:
{
// string | number: a unique identifier for the dispatch
id: 'abcdef123',
// any: Symbol, string, number, object, function. A unique way to identify the action dispatched
type: ActionTypes.ADD_TODO,
// any: whatever is being dispatched
payload: { text: 'Create FSA Proposal' },
// information about the action itself
action: {
// string representation of the particular action type
// since Symbols are not strings and action type can be anything, having a way to identify an
// action as a string is useful for serializing, debugging, and logging.
id: 'ActionTypes.ADD_TODO'
},
// other information about the dispatch
meta: {
// no opinions here...
status: 'success'
}
}
There's a difference between dispatch and action. I need to uniquely identify dispatches, this is useful for time travel, rollback, etc. I also need to be able to unique identify actions, this is good for logging and debugging.
I think this is a good MVP. I was using details
for action information in alt but I think action is a better name.
There is typescript but it were cool when flow were supported too
Branch | Build failing π¨ |
---|---|
Dependency | conventional-github-releaser |
Current Version | 1.1.7 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As conventional-github-releaser is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Sorry if I'm late to the party on this one, but:
https://github.com/angular-redux/store/blob/master/articles/strongly-typed-reducers.md#consider-using-flux-standard-actions-fsas
Opening this issue to track discuss whether FSA should address optimistic updates. If it does, I think it should be as an extension of the core spec.
In one example in the redux docs, higher order reducers are implemented with the help of a name
property on the action to specialize the action to a given specific reducer.
http://redux.js.org/docs/recipes/reducers/ReusingReducerLogic.html
How is this supposed to work for FSA, since the actions are not allowed to have a name property ?
I'd like to be able to handle the fact that some async action has started, and have state reflex that.
Why is type
defined like
The type of an action identifies to the consumer the nature of the action that has occurred. Two actions with the same type MUST be strictly equivalent (using ===). By convention, type is usually string constant or a Symbol.
Two actions with the same type MUST be strictly equivalent
. But if they have different payloads, this is not true anymore.
This doesn't make sense to me.
This is a TypeScript question.
If I define an action expected certain meta, if the action is an error, should the error action still enforced that there should be a meta?
payload: Payload
and
meta: Meta
are not defined as optional properties (with "?")
yet they are supposed to be optional. I have not been able to get this to work without explicitly null values; is there a way to have an action with only a type, or are these fields not optional?
I use the redux-actions
&& redux-promise
and React-Native 0.17
,but the RN17
use babel 6
,and and redux-actions
&& redux-promise
dependency flux-standard-action
which use babel 5
so ,My Project can not be builded success, so that I have to change the React Native
to 14
So,Could you update to the Babel 6
?
Should FSA mandate actions to be serializable? I think it's a good requirement (prevents people from passing callbacks inside actions). It's also great for the tooling, as it's easy to build Flux over websockets, or a persistent debug session solution, without worrying that something might get lost.
I propose the following changes:
invariant(isDeepEqual(action, JSON.parse(JSON.stringify(action))))
type
must be a String, not a SymbolWe could then write a middleware that checks actions for compliance in development.
Branch | Build failing π¨ |
---|---|
Dependency | eslint-config-airbnb-base |
Current Version | 11.0.1 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As eslint-config-airbnb-base is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
The Redux BDFL has mentioned before that Symbols as action types is a bad idea.
We're considering dropping support for Symbols in redux-actions, and wanted to cross-post that issue here since this is really about FSA shape.
Is anyone using Symbols as action types? What are the advantages over using strings? Standardizing on strings would lead to conceptual simplicity and potentially less special-casing.
How do you manage a FSE which is a GeoJSON-object? Any suggestions? Putting the Geojson in it's own key?
Branch | Build failing π¨ |
---|---|
Dependency | cross-env |
Current Version | 3.1.4 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As cross-env is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
<a name"3.2.0">
The new version differs by 4 commits .
dad00c4
feat(revamp): revamp the entire lib (backward compatible) (#63)
e33a85c
docs(README): Add doc for cross-var. (#58)
5e590ec
docs(README): added how to use cross-env to run npm sub-scripts (#53)
afdb2de
docs(README): mention BashΒ onΒ Windows (#49)
See the full diff.
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
This is pretty minor and trivial, but should be addressed nonetheless. It seems that the entirety of the type definitions use the order of <Type, Payload, Meta>
(or equivalent). However, ErrorFSA
was not updated to use this new order.
That being said... I don't really understand why the ordering was changed... With this new ordering, all apps that use flux-standard-action
now are required to define a type
if they want to define a Payload
or Meta
. For many codebases, the type will remain as string
. In my company's codebase - we have had to add a string
to almost every instance of FSA
(and derivatives).
It seems really weird that the only type that has a value used so commonly that it gets a default should be forced to be first. It being last makes the most logical sense imo; if you want to define just a Payload
or Meta
, you are not forced to also add a string
that would otherwise be set by default.
I'm coming to flux from a Rails/Ruby world (gasp!)
As I'm wrapping my head around Flux and standards (like FSA) I'm finding some questions pop up in my head, and whom better to answer than the FSA community/creator.
In FSA why is error state the job of the Action? That seems like we've overstepped, and for the wrong reasons. I don't think it's the action's job to choose something like validity (validity is a state).
An action is an abstract description of an operation to be performed. In databases you have transactions, in Android you have Intents, and in Rails you can attempt to modify a Model, but there's no guarantee that it will succeed, or yield a change. Should that be an error state? I think the reducer knows best.
Think of this:
I can't buy -1 of something, but who's job should it be to tell me that? When I press the minus button on a cart, should my action check state to see if I'm at zero, and violate separation of concerns? Or should it just fire the action and my reducers take care of state (one managing my cart number at zero and another showing a red exclamation mark animation). Ok, not a great example, but I think it expresses the point. I feel errors shouldn't be part of actions, and I'm interested in hearing why otherwise.
TL:DR; The error flag in FSA is bad
{
type,
status,
payload: {...}
meta: {...}
}
This would keep the top-level action object predictable β 1 required property (type
), and 3 optional properties. All other properties at the top-level would be invalid.
Branch | Build failing π¨ |
---|---|
Dependency | eslint-config-airbnb-base |
Current Version | 11.1.3 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As eslint-config-airbnb-base is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Hi there, have you ever considered providing a basic class/factory function as the default export for the package? It'd provide some syntactic sugar when writing your actions. I imagine the usage would be kinda like this:
import Action from 'flux-standard-action'
export function setUsername(username) {
return new Action('SET_USERNAME', username);
}
If you're open to it, I can make the PR. Thanks!
I wrote an example of using fsa with barracks
. I'd write a PR, but I'm not sure where to put the link. What is your preferred location to link to the example in the fsa readme? Thanks!
Branch | Build failing π¨ |
---|---|
Dependency | mocha |
Current Version | 3.3.0 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
As mocha is βonlyβ a devDependency of this project it might not break production or downstream projects, but βonlyβ your build or test tools β preventing new deploys or publishes.
I recommend you give this issue a high priority. Iβm sure you can resolve this πͺ
Mocha is now moving to a quicker release schedule: when non-breaking changes are merged, a release should happen that week.
This week's highlights:
allowUncaught
added to commandline as --allow-uncaught
(and bugfixed)--no-warnings
and --trace-warnings
flags (@sonicdoe)The new version differs by 9 commits0.
7554b31
Add Changelog for v3.4.0
9f7f7ed
Add --trace-warnings
flag
92561c8
Add --no-warnings
flag
ceee976
lint test/integration/fixtures/simple-reporter.js
dcfc094
Revert "use semistandard
directly"
93392dd
no special case for macOS running Karma locally
4d1d91d
--allow-uncaught cli option
fb1e083
fix allowUncaught in browser
4ed3fc5
Add license report and scan status
false
See the full diff
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot π΄
Right now it is a bit diffuse when one should use meta
over payload
. Some more descriptive examples might be a good idea?
It works after removing .babelrc.
I for example have built a history management package that changes URLs based on action types and a routing config map. Using middleware, I add location
and prevLocation
keys to payloads, but I rather pass them as keys on the action, so that the payload would be what it was before adding my middleware. So would it really be a crime for a package to add additional keys?
ps. I could add my keys to meta
, but I feel like too many other packages are possibly hijacking that, and could break what I've put on the meta
key. That basically summarizes the benefits of allowing for additional keys--package authors can essentially namespace their "meta" data and therefore do a better job of preventing it from being fooled with. Perhaps it's just best application developers stick to these conventions so that they can take advantage of the larger number of supporting packages that conform to the FSA standard, but package developers can make the choice to opt out of such benefits if they choose.
I think this is quite limiting.
You say this β
Isn't that enough? What if I deal with a server that sends helpful error code and messages in case of failure? For example a 401 response may include something like this:
{
"code": "WRONG_PASSWORD",
"message": "Password field should not be empty"
}
So I naturally dispatch this object as payload and set { error: true }
.
I guess what you're implying is that I should put this error object inside the meta
property. This seems contradictory to me. This is object is obviously payload.
Another thing that bothers me is that I can't find a payload of type Error
useful for anything. It can only hold a string, so it's pretty useless to keep in state, isn't it? (not to say that strings are useless, but you can see that we could pass much more information about the error)
Is it safe to assume that action creators should always have the following signature?
export function someAction(payload, error, meta) {
return {
type: SOME_ACTION,
payload,
error,
meta
};
};
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.