Not Another To Do App
Getting your hands dirty and feet wet with Open Web Component Recommendations…sort of: Part 6
Welcome to “Not Another To Do App”, an overly lengthy review of making one of the smallest application every developer ends up writing at some point or other. 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 your in the right place and should read on! If not, it’s possible you want to start from the beginning so you to can know all of our characters’ back stories…
If you’ve made it this far, why quit now?
Make it a Reusable Part
When working with a specific component model it’s easy to get tricked into thinking that every piece of UI that you want to reuse should be structured in the form of that component model. In my application I chose to work with the component model native to the web, the web component, but what about when I don’t need/want to be encapsulating things within the shadow DOM, or when there isn’t state specifically related to the DOM in question to be managed over the lifecycle of the component/application? In these cases, I turn to lit-html and its functional approach to template creation.
const reusablePart = () => html`... Your reusable part here ...`;There are innumerable contexts where this pattern is valuable in the development of an application. We’ve actually already seen it, possibly without knowing it, when correcting the.map linting error in a previous installment I moved the template part to /src/to-do-ui.js which simultaneously takes advantage of this pattern while allowing for the code to be reused in the testing process:
import { html } from 'lit-element';export const renderTodo = todo => html`
<to-do .todo="${todo}">${todo.todo}</to-do>
`;export const renderTodos = todos => todos.map(renderTodo);
Here we see our list of to dos (renderTodos) being made by mapping the todos array across the renderTodo template. The renderTodo template is then leveraged in the testing process to easily create the to-do fixture we run out tests against.
import { renderTodo } from '../src/to-do-ui';// ...const newToDo = {
id: 2,
todo: 'New To Do'
};
it('is a to do', async () => {
const el = await fixture(renderTodo(newToDo));
expect(el.textContent).to.equal(newToDo.todo);
expect(el.todoId).to.equal(newToDo.id);
});
#winning
One of my favorite applications of this technique is for injecting SVG icons into my templates. ${iconPlus} and you’re done! It’s so useful, and presents such an interesting array of usability, a11y, and code reusability questions that I’m investigating way that sets of tagged template literal based icons could be shared not just cross project, but also cross framework via feather-template-literals. However, I’ll leave getting deeper into that for another day. In the case of my To Do app, there’s just two icons; iconPlus and iconMinus. Both came out roughly like the following:
export const iconPlus = html`
<svg
xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 24 24"
fill="none"
stroke="currentColor"
stroke-width="2"
stroke-linecap="round"
stroke-linejoin="round"
aria-hidden="true"
>
<line x1="12" y1="5" x2="12" y2="19" />
<line x1="5" y1="12" x2="19" y2="12" />
</svg>
`;This is absolutely the most minimal implementation of this technique; every attribute is fixed, a11y is rented from the button the icon is in rather than applied to the icon, etc. From there, there are a number of other customizations that could be added, and now, if you make them, they’re centralized in one place for reuse across your entire project. Or, go the extra mile, break this out into its own package (or use mine, PRs welcome) and make it a dependency of as many projects as you’d like.
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 ongoing conversations into a measly ten sections. Congratulations, you’re nearing the end of the sixth! Are you starting to notices things about To Do apps that you previously couldn’t with just your eyes and ears? Do you see To Do apps?
- Not Another To Do App (Maybe now I can just use these reusable parts and never write another To Do app again…)
- Getting Started
- Test Early, Test Often
- Measure Twice, Lint Once
- Make it a Component
- Make it a Reusable Part (you are here)
- 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 and issue, submit a PR, or fork a repo to get in on the action!
