Intelligence Center

Appearance

Element Naming ​

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

Summary/Cheat Sheet ​

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.

Active Elements: ​

  • input_user_name
  • input_product_quantity
  • onsubmit_create_user
  • onsubmit_create_cart_item
  • onload_get_user
  • onload_get_products

Reactive Elements: ​

  • product_item
  • product_title
  • product_category_tag
  • product_price
  • user_profile_avatar
  • user_profile_first_name
  • user_profile_last_name
  • user_profile_tier

Active elements ​

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

input_element ​

Inputs should be named as follows:

  • input_user_name
  • input_product_quantity

trigger_request_name ​

Trigger elements should be named by using an optional action qualifier (e.g., submit, load) and then the request name:

  • onsubmit_create_user
  • onaction_create_cart_item
  • onload_get_user
  • onload_get_products

Reactive elements ​

component_name_element_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.

  • product_item
  • product_title
  • product_category_tag
  • product_price or
  • admin_user_profile_avatar
  • admin_user_profile_first_name
  • admin_user_profile_last_name
  • admin_user_profile_tier

This gives us a clear distinction between elements that trigger an action and elements that are affected by an action.

"Don't repeat yourself" (DRY) ​

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:

  • Signup
  • Login
  • Request password reset
  • Confirm password reset

There is no need to give a unique name for each email field like so:

  • input_signup_email
  • input_login_email
  • input_request_password_reset_email

Instead, use a generic name like this:

  • input_email

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_default and 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: onsubmit_create_user

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.

Conflicts ​

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.