Situation: several developers working remotely on different section/modules of a SPA.
As a result they may accidentally introduce HTML elements with the same id
. What are the common ways to avoid that situation (without refusing id-usage if possible) before final assemblage?
My shallow guesses:
pre-arrange id
for all names(a bit ridiculous but...)
structure names with architecture e.g. for an app/collection/model
dedicate a name like app-collection-model
refuse using id
s in general or use only for large modules?
If you are writing the same HTML code again and again with different IDs you are doing something wrong.
Nowadays, there are many ways of creating reusable HTML components that do not need IDs.
What I think is wrong:
For big projects (multiple teams involved or big amount of views) I don't think writting again and again raw HTML is a good idea.
That approach means: duplication of code and pain to refactor in the future (think about a restyle of the application in 2 years). That's why there are so many UI frameworks out there that help to create reusable components where HTML is written only once and used anywhere. At the end, your application will require a few components: table, popup, form, submenu, tabs..
The goal is to create a framework with those components that a developer can use to create a view without the need of actually writing any HTML code.
My point is: HTML code should be written once and only once in big projects. Obviously the fact that it's written once doesn't mean that it can only be rendered in one place, it can be anywhere in the application.
My suggestion:
Data-binding to the rescue!
If doing a big change is not possible, convention is the way to go. The one that you propose could make sense but be careful, every time that you change the structure all your IDs will be wrong!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With