How do you name your computed properties and actions?
For example, suppose you have a settings-manage-panel component that should only be shown if the user is an administrator. You therefore make a boolean computed property that is true if the user is an administrator, or false if the user is not. Do you name the property userIsAdmin or do you name it showManagementPanel? Basically I’m asking should the computed property be named after what it is or what it’s used for?
Similarly, suppose you have a form with a submit button that creates a new post resource. Do you name the action postFormSubmitted or createPost? Worded differently, should actions be named after what caused them or what they should do once triggered?
It doesn’t matter. Different people do different things, and it’s entirely down to preference. My only suggestion is to try to be internally consistent in your naming, and don’t worry too much about it.
Consider having TWO properties. Define the second (showManagementPanel) in terms of the first (userIsAdmin). Later, when the logic for showing the management panel changes, you can redefine that property, without affecting the semantics of the first.
You can follow the same approach with actions. Name the action itself after the user action (in your example postFormSubmitted, and implement it by calling a method called createPost.
In this approach, the template is only aware of the specific UI-related properties and actions (showManagement Panel and postFormSubmitted), and the mapping of those UI specifics to business logic (showing the management panel only to admins, creating the post when the submit button is pressed) is defined in the JS logic.
I would have a CP on the user model called isAdmin. The component would receive an user model. In the template, you would bind it as {{user.isAdmin}}. The user part is implied through the model’s type. You don’t need another user- prefix to show that.
As for actions, I always suffix -Action to show that the property is an action. This avoids confusion with other properties. Action always indicate something to happen, as in, the user takes an action. So it should always be named in an imperative mood, as if the user is giving a command to the computer. The computer react to the command by binding new data into the view. So for your example, it should be named as createPostAction.
Thanks for your reply! Moving isAdmin to the user model could be a great solution to my simple example, depending on the complexity of the use case. In some situations, isAdmin may actually depend on more than just the user, for example if we are computing whether the user is an admin of a certain page or group. In any case, the purpose of the example was to draw attention to property naming conventions, as opposed to refactoring.
Do You have only Admin/User?
Or maybe more?
Dou You plan on hard coding all the acces rules? Or maybe plan on configuration tool for access and roles?
If it is one of the letters, You should rethink that property into new service that can be queried for user and action.
Like:
Authorization.canDo('action name’s, user);
This way You can have roles definitions in one place, and if You need configuration page then role us just set of actions which can be gathered at build time, so adding new actions is developer responsibility during writing code, but managing roles is business administrator afterward.