Getting your hands dirty and feet wet with Open Web Component Recommendations...sort of.
This a cross-post of a Feb 26, 2019 article from Medium that takes advantage of my recent decision to use Grammarly in my writing (so, small edits have been made here and there), thanks for looking again if you saw it there đđ˝ââď¸ and if this is your first time reading, welcome!
Welcome to âNot Another To-Do Appâ, an overly lengthy review of making one of the smallest applications every developer ends up writing at some point or another. If youâre here to read up on a specific technique to writing apps or have made your way from a previous installation, then likely you are in the right place and should read on! If not, itâs possible you want to start from the beginning so you too can know all of our charactersâ backstories...
If youâve made it this far, why quit now?
Measure Twice, Lint Once
It may already too late to stop an exasperated comment or two from readers that have made it this far in response to a somewhat questionable block of code shared in a previous section. While accurately delivering the content to our application that is needed to pass the test of âit renders to do elements to the DOM for each of the to-do items in your listâ, the following code sample sparks the ire of another feature that the open-wc team has provided our application:
render() {
return html`
${this.todos.map(todo => html`
<to-do>${todo}</to-do>
`)}
`;
}
Linting!
As you can see in the terminal readout above, the inclusion by open-wcâs generator of eslint-plugin-lit
gets right into helping your write cleaner, more performant code with a number of rules built for lit-html
based templating. Beyond not getting to rely on .map
in your templates, youâll also be told when youâre binding the same attribute multiple times to a single element (i.e. <x-foo bar=${x} bar=${y} baz></x-foo>
), when youâre redundantly using template literals (i.e. foo ${âbar'}
), when youâre bindings are in invalid positions (i.e. <x-foo></${expr}>
), and much more. Luckily, in the case of my .map
the steps to correct the error are few, they make our template much more readable, and they prepare the code for reusability as weâll get into later.
import { renderTodos } from './to-do-ui';
// ...
render() {
return html`
${renderTodos(this.todos)}
`;
}
However, this is not the only part of the lint report that surprised me. The following caught me as well:
I actually tripped this alert in two related places (one on the application side, one of the testing side of the same feature) so the logic to correct one mostly applied to the other. In the case of one instance, the code was as follows:
for (const todoCount in workLevelByTodoCount) {
if (todos.length <= todoCount) {
return workLevelByTodoCount[todoCount];
}
}
return Object.keys(workLevelByTodoCount).length;
Which when delivered via object/array methods get you the same functionality with a little bit more clarity while youâre at it:
const workLevelCounts = Object.keys(workLevelByTodoCount);
const count = workLevelCounts
.find(todoCount => todos.length <= todoCount);
return typeof count !== 'undefined'
? workLevelByTodoCount[count]
: workLevelCounts.length;
Beyond the above results, I was also hit a number of other smaller linting errors and warnings that Iâm glad to have out of my code base with the first call to git commit -am 'Code with some linting errors'
. Itâs nice to know someoneâs got your back when it comes to these little nit-picks that can have compounding negative effects on your code over time.
Whatâs More
Itâs also nice when the tools a project adds to help itâs users be better (like this linting on commit) does the extended work of helping to make the project itself better. Once I had finished working through my list of linting issues, I found that there was an extra one that I couldnât explain.
Turns out that some things had slipped by in the development process of the generator. Shortly after catching this and submitting an issue in the open-wc project, it was tidied right up.
The Short Game
As voted on by a plurality of people with opinions on such topics that are both forced to see my tweets in their Twitter feed and had a free minute this last week, a 9000+ word article is a no, no.
So, it is with the deepest reverence to you my dear reader that Iâve broken the upcoming conversations into a measly ten sections. Congratulations, youâre nearing the end of the first! If youâve enjoyed yourself so far, or are one of those people that give a new sitcom a couple of episodes to hit its stride, hereâs a list of the others for you to put on your Netflix queue:
- Not Another To-Do App
- Getting Started
- Test Early, Test Often (I could use some unit tests on these articles...)
- Measure Twice, Lint Once (you are here)
- Make it a Component
- Make it a Reusable Part
- Does Your Component Really Need to Know That?
- Separate Things Early, Often, and Only as Needed
- Some Abstractions Arenât (Just) For Your App
- Reusable and Scaleable Data Management/And, in the end...
- See the app in action
Special thanks to the team at Open Web Components for the great set of tools and recommendations that theyâve been putting together to support the ever-growing community of engineers and companies bringing high-quality web components into the industry. Visit them on GitHub and create an issue, submit a PR, or fork a repo to get in on the action!
Top comments (0)