-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Consistent naming strategy for buttons and plugins #8033
Comments
TODO:
|
IIRC - we had For the UI button in #8002 it could make sense to have And for this case |
OTOH it allows grouping button names by features (feature->action: But given the popularity of verb+noun across the project, I agree it's an inconsequence and this should be fixed. Besides, it also does not work in terms of natural language (insert what vs. what insert). |
As discussed on the meeting 👍 for the change in image buttons and to describe the naming convention. |
We should change the names in this iteration because we introduced the new We do however have to remember to fix those names in the changelog as it currently holds the notion of |
I reviewed command names and these are trickier. There are more types of their names. However, again some of the image commands stand out. Namely, I'd fix these names: imageInsert, imageResize, imageUpload, todoListCheck. These are the only 4 commands that have noun+verb structure. I'd rename them to insertImage (matches the new button name), resizeImage, uploadImage (matches the new button name) and checkTodoList. Feature name (noun-based)Note: Many of these names could also be moved to the next category as they are both nouns and verbs. I moved there only
Feature-related (verb-based)
Feature + sub-feature (noun)
Verb
Feature + action (verb)
|
My biggest issue with all this is that inside the image package now we'd have:
But the same is true for tables and it never drew my attention – it felt fine so far. So perhaps I'll get used to the image names too. |
👍 sounds natural
👍 I'll second this, having those in tables seems OK so in the image would be OK also. Naming is tricky as we have both noun/verb features. Having two patterns is ok as
Reading above alongside others seems kinda odd, maybe Side note: we do
|
Actually, Anyway, I'm fine to have |
Doh, one more question/problem – should class names be changed too? In general – should they follow the name under which the button/command is registered or the plugin name + sub-feature convention? I'd go with following the name of the button/command. |
Oh yeah. Definitely 👍. |
@Reinmar @jodator I wanted to sum up what needs to be done for @psmyrek. Please check the below and see if I'm missing something.
|
Those should be |
Below is a summary of what I will change: Buttons
Commands
@Reinmar @jodator Should the commands also have an alias (old name) for backward compatibility, or just buttons? |
Should the file names also be renamed to reflect the class name change (e.g. Currently, files are sorted nicely in the IDE (basing on the "feature" part), but some file names will not match the class name that will be defined in them:
On the other hand, if we change the names of some files, then they will not sort well in the IDE anymore... |
Both. ps.: I've edited your post and added:
Yes. (remember to change also test file name and the For the file names vs feature path. I think that this is OK.
Because the command name follows a specific convention here it will be easier to find This also brought my attention to keep in mind to update jsdocs paths as well when you'll rename a class. The /**
* @module image/imageupload/uploadimagecommand
*/ |
Other: Unified buttons, and commands naming convention. Old values are available as aliases. Read more about those changes in the [Code style](TODO:URL_TO_OUR_DOCS) guide. Closes #8033. Changes in toolbar buttons (before → after): - `imageUpload` → `uploadImage` - `imageResize` → `resizeImage` - `imageInsert` → `insertImage` - `imageResize:*` → `resizeImage:*` Changes in command names: - `imageInsert` → `insertImage` - `imageUpload` → `uploadImage` - `imageResize` → `resizeImage` - `forwardDelete` → `deleteForward` - `todoListCheck` → `checkTodoList` MAJOR BREAKING CHANGE (list): The following module `list/todolistcheckedcommand~TodoListCheckCommand` has been moved to `list/checktodolistcommand~CheckTodoListCommand`. MAJOR BREAKING CHANGE (image): The following modules have been moved (before → after) - `image/image/imageinsertcommand~ImageInsertCommand` → `image/image/insertimagecommand~InsertImageCommand` - `image/imageresize/imageresizecommand~ImageResizeCommand` → `image/imageresize/resizeimagecommand~ResizeImageCommand` - `image/imageupload/imageuploadcommand~ImageUploadCommand` → `image/imageupload/uploadimagecommand~UploadImageCommand`
Buttons
Verb + noun (optional):
Noun + verb:
Noun (usually, a feature name):
Observation and proposal
IMO, the "noun + verb" category is an inconsequence.
Proposal
Plugins
Feature name:
Feature name + sub-feature:
Exceptions:
Observations
We're quite consistent here. There are either
[FeatureName]
plugins or[FeatureName][SubFeature]
ones. There are some exceptions, but I'd say reasonable.More importantly, though, we can see that if the
[SubFeature]
part is a verb, the button name diverges from the plugin name. A special case here isinsertTable
vsTable
and in some senseinsertImage
if it was registered byImage
as proposed in #8002. I don't see a problem here, though. I don't think we need to have plugin == button names equality.tl;dr: I don't think we need to change anything here. We should hace
[FatureName]
and[FeatureName][SubFeature]
plugins with some room for exceptions where it makes sense.If you'd like to see this improvement implemented, add a 👍 reaction to this post.
The text was updated successfully, but these errors were encountered: