Can we usehttps://github.com/acdlite/flux-standard-action/#isfsaaction?

Ah - yes. Will change.

Though, that method doesn't check if thetype is aString orSymbol. I'll go make a PR there ;) [unless you're opposed]

Well... actually...

Thetype of an action identifies to the consumer the nature of the action that has occurred. Two actions with the sametype MUST be strictly equivalent (using ===). By convention,type is usually string constant or a Symbol.

The wording here tells me I probably shouldn't enforce types on thetype property? Say if someone wanted to use numbers for their types for whatever reason. What do you think?

Sounds good. Though, we may be dropping Symbol support soon#126.

Can we standardize oninvariant?

Could you teach me whatinvariant does/is for?

It's a way to ensure that application the application is in the right state, and throw errors otherwise. React and Redux use this quite a bit. We're starting to standardize on this in#127,#129, and#131.

done :)

I'm not familiar with.editorconfig. Can you quickly teach me what value this adds?

Sure!EditorConfig is really good for keeping line endings, indentation, trailing spaces and so on and so forth in sync between different IDEs. It's just a quick headache reducer as long as contributors have it installed in their editors (some of which have it bundled out of the box).

Cool. I recently switched from Webstorm back to Sublime Text, so it looks like I'll have to download a plugin.

What happens if a rule here is broken? Does the build fail? What value does this add beyond linting?

It doesn't do linting, it just works inside the editor make those things happen (eg. tabs = 2 spaces, or all files get a newline at the end).

Can you create a single commit or pr for this as well pls?

@timche#144 :)

For this and the tests below:

• can we use the identity function from lodash?
• can we inline the call tocreateAction (action1 is not used elsewhere)?

Also, unless there's a good reason to disablemax-len, let's stick to it. Since we're testing an exact match, can we use the string directly?

max-len is because the message is longer than 100 characters, so I think it's reasonable to disable it. The regex was in case any of you wanted to change the messageedit: ie. have a little less dependence in the test on the exact message... but obviously ATM it's just a direct copy/paste.

I'd like to push back again on theeslint-disable-next-line max-len and the use of a regular expression here.

I'd like to use these overrides only where they must be used. In a 20K line production application, I've seen this happen only in two places:

• directly consuming snake-cased fields from the API on the client (eslint-disable-next-line camelcase)
• early returns from iterators inlodash (eslint-disable-next-line consistent-return)

It wouldn't be a rule if we were permissive about bypassing it; the value of the rule comes from a widespread adherence.

I also think we should strive for consistency with respect tosimilar tests in the repo.

To that end, let's test the error class thrown, so callers know what to catch, and the exact string (I don't think the flexibility afforded by using a regular expression object buys us much).

Done. Thanks for the feedback!

invariant only throws a regularError and I didn't want to introduce matchers just to check for the error name to be "Invariant Violation". I didn't see it being much value, but the format should be consistent now.