About Naming Rule -Front-end

I always think about what is the best way about naming. You can name what you want in your side project. You may remember what you name before, maintain by yourself. But what if you co-work with others? What is the best rule that everyone can get started quickly and easy to maintain?

Before start

We may have some component, some generator, some data for Form, Table, some button to handle… some variables, some function. Following is what I name in my project.

return Boolean

series like “isXXX”, “hasXXX”, “shouldXXX”… I will know that it always return Boolean type of variable (no matter it’s a variable or function)


isXXX:

  • isMobile
  • isUserExpired
  • isSocialUser
  • isEmailVerified
  • isFormValid
  • isEmpty
  • isFreeUser
  • …etc

hasXXX:

  • hasThumbnail
  • hasCreditInfo
  • hasSomeProperty
  • hasLabel
  • hasCoupon
  • hasSubNav
  • hasFillCreditInfo
  • …etc

shouldXXX:

  • shouldShow / shouldHide
  • shouldSuccessModalShow / shouldPasswordFormShow / shouldAlertShow
  • shouldDisabled
  • shouldPayButtonDisabled
  • shouldRemindUpgrade
  • …etc

they all return Boolean type variable. They are very similar but use in different place.

handle method

series like “showXXX”, “handleXXX”, “onXXX”, “getXXX”, “setXXX”… I will know that it will do something inside function (always function)


showXXX:

  • showUserModal
  • showEditModal
  • showDeleteModal
  • showCreditModal
  • …etc

Of course, just pass variable to “showModal(modal)” and handle in different function.

handleXXX:

  • handleEditModal
  • handleAlert
  • handleUserForm
  • handleMenuTab
  • handleError
  • handleSocialLogin
  • …etc

onXXX:

  • onStateChange
  • onPageLeave
  • …etc

getXXX / setXXX:

  • getProperty
  • getUserType
  • getItem
  • getPlanTitle
  • …etc
  • setProperty
  • setUserProfile
  • setItem
  • …etc

variables

  • selectedPlan
  • activeItem
  • …etc

async API call

get some async data

  • fetchUser
  • fetchCreditInfo
  • …etc

set some async data

  • updateUser
  • updateCreditInfo
  • createUser
  • deleteUser
  • …etc

continue handle

sometime we may separate our code with dirrerent function after get async data or just too much code in one funtion

  • continueLogin
  • continueSignup
  • continueSignupByPlan
  • …etc

components / generators

naming like xxxComponent

  • userTable / operationTable / billingTable
  • userForm / passwordForm / emailForm /
  • sussessModal / userModal / deleteModal
  • …etc

Note

I always named as following when I handle some async request:

ex: signup flow:

First get “signupForm”(maybe in signupModal) data to “handleSignup” function, prepare “formDate” / “payload” for async request.

Then, call signup (async request) and we may have many things to deal with after callback. If there is more handle then we can use “continueSignup” function.

everything can follow the rule. Just like this.

— — — — — — — — — — — — — — — — — — — — — — —

If you get the logic. you may reduce the time when you naming and get less trouble. Always thinking the best name for your variable / function. Just sharing what I’m thinking.

Thanks