-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Prettier should have a better opinion on createSelector() calls #5285
Copy link
Copy link
Labels
help wantedWe're a small group who can't get to every issue promptly. We’d appreciate help fixing this issue!We're a small group who can't get to every issue promptly. We’d appreciate help fixing this issue!lang:javascriptIssues affecting JSIssues affecting JSlocked-due-to-inactivityPlease open a new issue and fill out the template instead of commenting.Please open a new issue and fill out the template instead of commenting.
Milestone
Metadata
Metadata
Assignees
Labels
help wantedWe're a small group who can't get to every issue promptly. We’d appreciate help fixing this issue!We're a small group who can't get to every issue promptly. We’d appreciate help fixing this issue!lang:javascriptIssues affecting JSIssues affecting JSlocked-due-to-inactivityPlease open a new issue and fill out the template instead of commenting.Please open a new issue and fill out the template instead of commenting.
Prettier 1.14.3
Playground link
Input:
Output:
Expected behavior:
I understand that currently prettier applies its rules regardless of context, but in case of reselect createSelector() calls this really reduces readability. The style that can be found in pretty much all examples of reselect and projects using it is very straightforward: One input selector per line, and then the callback to combine the input.
However, due to prettier's preference of wrapping a callback argument if everything else fits in the same line (or even fitting everything in the same line), the resulting code is harder to read. It's also inconsistent if you have multiple selectors in the same file and depending on the length of their arguments they sometimes get wrapped and sometimes they don't.
One possible option for this could be to have some default overrides for certain function names, e.g. "one argument per line" for createSelector. I realize this might get close to "too much configuration" territory but it could always use a hardcoded list (or sane defaults) - also, easy-to-read/understand code should be a top priority IMHO, and that's not the case with the current formatting here.