Master our element naming convention for organized, readable, and collaborative frontend projects.
This page explains how we can approach naming Wized elements to help you stay organized in your project.
We recommend putting all Wized elements into two buckets:
- Active Elements - Elements that trigger actions
- Reactive elements - Elements that are affected by actions
Here's a quick summary of our naming convention. If this is your first time on this page, we encourage you to skip the cheat sheet, and read on from there.
The names for Active elements start with any of these 3 words:
- input - signifies an input element
- onaction - fires a request after a user interaction
- onsubmit - fires a request after a user submits a form
- onload - used for requests that happen on page load
Inputs should be named as follows:
Trigger elements should be named by using an optional action qualifier (e.g.,
load) and then the request name:
For elements that are supposed to be used as template elements, or elements that are affected by a request state fall in the reactive elements category.
These elements should be named by using the component name, and then element name.
This gives us a clear distinction between elements that trigger an action and elements that are affected by an action.
Just like you do with classes, try to reuse Wized element names, and keep the number to a minimum.
In other words, avoid redundancy.
For example, let’s say you have 4 Auth forms:
- Request password reset
- Confirm password reset
There is no need to give a unique name for each email field like so:
Instead, use a generic name like this:
This element can be reused in multiple requests with ease since in most cases the requests are on separate pages.
Additionally, loader attributes are perfect candidates for reusability.
When indicating the loading state of various elements, you can use a generic loader attribute like
loader_defaultand apply it to multiple elements throughout your project. This way, you maintain consistency while reducing the number of unique attribute names.
The only place where you need a unique name is on the request trigger. There, you should use the name of the action that the request is supposed to perform. For example:
By embracing the DRY principle, you'll enhance organization, readability, and collaboration in your Wized projects, making it easier for developers to understand and maintain the code.
If you're in a conflict with naming, don't overthink it.
Just make a decision and move forward.
The decision to give a good name to an element is not always clear. That's ok. Pick something and move on.
Taking any significant time to think about naming is not advised. Breaking your workflow to overthink naming is also not advised.