Getting your hands dirty and feet wet with Open Web Component Recommendations...sort of.

This a cross-post of a Feb 26, 2019 article fromMedium 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 tostart from the beginning so you too can knowall of our characters’ backstories...

If you’ve made it this far, why quit now?

Does Your Component Really Need to Know That?

It’s hard to say whether it comes from my training in Agile, or my learnings about Lean, or my training in agile (big A, little a, if you know...you know), or my own musings on theMTU, but I’ve grown quite fond of not doing things that don’t have to be done. Along those lines, I often have overly long conversations with myself as to where I should position the control over a component; it’s content, it’s functionality, it’s styling, everything. I spent a good amount of time thinking about this particularly in relation to the implementation of my app’sto-do element.

Initially, in keeping with the least amount of work approach, I felt I could get away with comparing my to-dos with string-based equality. There was no data to define them beyond the text string of the to do, so I wanted to get away with code so simple as:

<to-dotodo="I've got stuff to do"></to-do>

A simple string meant I could rely onattribute binding to push the necessary data into myto-do element, and I could call it a day. However, a quick self QA (quality assurance test) of this will show you the folly of this in a simple equality world:

<to-dotodo="I've got stuff to do"></to-do><to-dotodo="I've got stuff to do"></to-do>

When you’ve got two to-dos of the same name, you also have two to-dos of the same equality, which means that “completing” one willaccidentally complete both. What’s a person with lots of to do with the same text to do?

First, I thought to do this:

<to-dotodo='{"todo": "I'vegotstufftodo"}'></to-do><to-dotodo='{"todo": "I'vegotstufftodo"}'></to-do>

Thanks to theLitElement base class that open-wc’s Starter App supplies to build my web components with, I could declare mytodo property as{type: Object} and I’d get the serialization of that attribute string into an actualObject for free. That object would then have a unique identity between my individualto-do elements and I could rely on equality checking again to “complete” one to do and not the other, and all was right with the world.

Wrong

Relying on data that is being serialized across a component boundary internal to an application means that new identities are going to be created at times that are likely not the ones you meant. Particularly, when serializing into and out of a string via the binding outlined above, the external and internal identity of your objects will not be shared, which is how I had made my way to the following code:

<to-do.todo="${todo}"></to-do>

Using property binding means that we can skip the requirement for string serialization and that not only will eachto-do element have atodo with a unique identity, regardless of the work needed to display them, but that identity will also be maintained across component boundaries. Rich data communication in a web component? You don’t say...

With that decided, I spent a little time with the style application I hoped to achieve. I decided to invert the standard styling approach and rather than rely onto-do element internals (with the likely help of CSS custom properties) to style the to do text, I chose to apply it through the light DOM so that the parent element would have control of the styling. It’s a small difference, but it’s one less thing that my custom element has to think about.

<to-dotodo="${todo}">${todo.todo}</to-do>

What did I tell you, a small change! And, internally this change is paired with the addition of aslot element to display the content projected into yourShadow DOM from outside. In this case, that looks like:

render(){returnhtml`        <div>            <slot></slot> <!-- <E<=<- Look, I'm a slot! -->        </div>        <button            @click="${this.completeToDo}"            title="Complete To Do"        >${iconMinus}        </button>    `;}

Sometimes your components need to know more than you initially hope that they will need to, whether for maintaining their fidelity internally or for doing the same across component boundaries when constructing an application. Other times, you might be able to take some responsibilities off of the shoulders of your components. Getting philosophical and answering the question “Does Your Component Really Need to Know That?” can be an important step in both delivering the features you’re putting together now, as well as reducing maintenance requirements for later.

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 (Remember this, oh so long ago, we were but children then..)
• Test Early, Test Often
• Measure Twice, Lint Once
• Make it a Component
• Make it a Reusable Part
• Does Your Component Really Need to Know That? (you are here)
• 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 atOpen 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!