In this case the class
btn_view is the hook that JS uses for listening to or manipulating the DOM. The choice of what to use for these hooks may seem inconsequential at first but it is an important decisions that can aid a lot with the maitainability of your application.
So I want to share my conclusions on best practices for adding JS hook in DOM elements.
Note: This is not a big concern in Frameworks like Angular and Ember as they rarely rely on these kind of JS hooks to interactive with the DOM.
Note:: When I refer to
components in this post I am not talking about Web Compoments, but about reusable views that are added to the DOM, e.g. Backbone views.
The first obvious candidate is using an ID e.g.
$('#btn_view'). This is a very popular option, but it has a big drawback. IDs shouldn't be repeated in a page, meaning that you can only have one of each. This hinders reusability of components. E.g. you cannot have multiple views of the same component in a page because they use the same IDs.
This might not seem like a problem at the beginning, but at some point you might want to include many of the same components in a page and you will regret using IDs.
So my rule is that IDs should only be used for elements that I am 100% certain will not be repeated, for example the site main navigation or generated IDs (See the bottom of this post).
Note: Web components get away with this restriction as the elements inside a component are encapsulated, so using IDs is a perfectly good approach when building web components.
Aria roles are there to aid with accessibility of the page, it is a good practice to add them but don't use them for JS hooks, that is not what they are for. And don't invent roles that aren't recognised, for more information see here
Data attributes are meant to be used for adding any arbitrary data to your DOM, so on paper they are the best solution. e.g.
<a data-btn-view href="#">View</a>
This is not too bad if you don't mind writing selectors like
[data-btn-view]. I however decided that it is ugly enough to not use data attributes for JS hooks. At least until libraries and frameworks add a more concise selector for data attributes.
Classes are the other popular choice. They are very concise e.g.
$('.btn_view'). But they have a big problem, they are mainly using for CSS styling. This make using classes very brittle. What happens when someone decides that this element should not have that style anymore? Your JS might suddenly stop working. This can be a subtle bug and really hard to spot.
Still classes are the easier option with less problems. To avoid issues in the future all you need is some naming conventions. Instead of hooking on classes used for CSS, add extra classes to your elements just for JS and name them in a special way that makes sense to your team. e.g.
<a class='_btn_view btn' href='#'>View</a>
In this case I use the underscore (e.g.
_btn_view) to denote the fact that this is a class intended for hooking JS code onto the element. Everyone on the team will know that they shouldn't remove or change that class in that element, every other class e.g. btn is fair game.
Another popular alternative is using
js at the front of the class e.g.
If you need to have IDs in your components I prefer them to be auto-generated and only have one ID per component at the top level, e.g.
Then I pass the generated ID to the JS view code.
So my best practices for adding JS hooks to the DOM are:
- Don't use IDs, or only auto generate IDs on the top level of each component.
- Don't use Aria roles for JS hooks
- Data attributes are good but ugly to work with
- Don't use classes meant for styling
- Use classes named with a special convention e.g.
Do you have a best practice that works for you? Please let me know.
The Axioms of Software Development - Part 2
Type less when using Git on the command line with gitsh
The Axioms of Software Development - 1 of 4
reinteractive is Australia’s largest dedicated Ruby on Rails development company. We don’t cut corners and we know what we are doing.
We are an organisation made up of amazing individuals and we take pride in our team. We are 100% remote work enabling us to choose the best talent no matter which part of the country they live in. reinteractive is dedicated to making it a great place for any developer to work.
Webinars are our online portal for tips, tricks and lessons learned in everything we do. Make the most of this free resource to help you become a better developer.
The Ruby on Rails Installfest includes a full setup of your development environment and step-by-step instructions on how to build your first app hosted on Heroku. Over 1,800 attendees to date and counting.
The Ruby on Rails Development Hub is a monthly event where you will get the chance to spend time with our team and others in the community to improve and hone your Ruby on Rails skills.