Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor to remove usage of post related effects in packages/editor. #13716
Refactor to remove usage of post related effects in packages/editor. #13716
Changes from 1 commit
7e1d857
77a812c
ae3f60b
a673b8e
25c74c2
54fbc38
455d6a8
5d246e5
0008288
de8e6d1
64216f4
f80fae4
97b1ed5
9bce642
36f962d
d69599f
4cba06a
b3beb7f
651216d
a455781
1a4fc0c
49f5af6
a41039c
2c14df4
f66af80
5568ac3
6d74643
ff70f2b
1c11a5b
4cc4015
0ba7d0e
c17179e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a compelling reason to segregate the two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean among the post actions? or do you mean specifically having "post" type actions and eventually "block" type actions?
If the former, I find it easier to know where to go for general actions as opposed to action generators. It also aids with splitting up tests to cover the specific things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't seem to me that it's something someone should need to distinguish. I think a current reality is that we have spaghetti generators, but they're all just "actions (dispatchers)", ideally returning or yielding simple action objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably ignorant of potential reasons why we wouldn't want to split up things in this case. Are there technical/performance/build reasons why its good to avoid splitting up files like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I usually try to logically split files up into smaller components when I can because:
a. it helps with finding things quicker when I'm just looking for a "class" of logic
b. it makes for smaller number of lines in a file, so less scrolling.
c. My IDE built-in linting etc doesn't get bogged down as much due to larger files.
But as I already mentioned, I'm aware I may be ignorant of good reasons for not splitting things up as I did here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, no directives. Just surfacing my own opinions stemming from the initial concern / probe for rationale of the split. It seems there's at least a second opinion in your favor from @youknowriad , but I'd go on record to disagree with the "domain"-based split (it wasn't but an hour after my previous complaint about the effects structuring that I wrongly navigated to
effects/posts.js
as my first destination in pursuit of this snippet of code).To your question, yes, I'd see it all just being in a single
actions.js
file.There's an interesting overlap between this discussion and some older ones like in #3030, where I think ultimately it was the introduction of
@wordpress/data
and its store-namespacing that served as the alternative to this problem of files becoming large and unwieldy, where the separation was by stores (modules), not by separate files within a store.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actions.js
is better if we had one file but if the file grows indefinitely, it becomes hard to navigate the file. maybe there's a middleground to find at some point.I also said to @nerrad that in general I'm not very opinionated on these matters :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya this is one criteria I use when deciding whether to split up a file. For example just with the post actions here, combined, they would be 487 lines. That's before adding in all the block and editor related actions.
@aduth my plan was to have
editor-actions
andblock-actions
files that would accompany thepost-actions
. That snippet is found within theSETUP_EDITOR
editor effect that would have landed ineditor-actions
(under the original plan).Would a middle ground here be to not split between action generators and action functions and just have
actions/post.js
,actions/editor.js
, andactions/blocks.js
? That might also be useful for aiding future refactors where some (or all) of the block specific actions are moved elsewhere.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep in mind, I'm not only considering the line count for a combined actions file, but also the line count that would be exponentially larger for the corresponding tests file. Currently combining
actions/test/post.js
andactions/test/post-generators.js
into one file results in 759 lines. As soon as a file gets over roughly 500 lines I find it starts to get unwieldy. I imagine the line count for a combined file of editor, post, and block actions tests will start to go over 2000 easily.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To explore this further then, are you suggesting that we might want to consider applying some more granular namespacing here and split these up into more stores? Of course, that could introduce some complications with deprecating the old actions etc but might be preferable over the file splitting. So we could end up with something like
core/editor/posts
,core/editor
(for general editor actions), andcore/editor/blocks
for block actions?