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

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!

Why To-Do Apps?

Every person to have written a To-Do app has likely each done so for a slightly different reason. Some out of boredom. Others in a sort of scientific pursuit. Many to learn something new. Often to actually manage things you’ve got to do. And, I’m sure, myriad others. Inherently, a To-Do app is a perfect mix of simplicity (you can often put some together in a matter of minutes) and complexity (it begs the answer to many important technical questions). If you’re into simplicity, your off-ramp is below:

let todos = [];

function render() {
    document.body.innerHTML = `
        ${todos.map((todo, index) => `
            <div>
                ${todo}
                <button
                  class="complete"
                  data-index="${index}"
                >
                    Complete
                </button>
            </div>`).join('')
        }
        <div>
            <input />
            <button class="add">Add</button>
        </div>
   `;
}

document.body.addEventListener('click', e => {
    if (e.target.classList.contains('add')) {
        todos.push(document.querySelector('input').value);
        render();
    } else if (e.target.classList.contains('complete')) {
        let index = e.target.dataset.index;
        todos.splice(index, 1);
        render();
    }
});

render();

Yes, this could absolutely be both simpler and smaller...I look forward to seeing the posts that prove that to be true! Starting productive conversations is a large part of why I write about the code that I craft, and if I can get a good one this early on I’ll be quite bullish for the rest of this series. However, it’s true that all you need to do is paste the above into the console of your favorite website and suddenly it too will be a To-Do app!

For those of you in Camp Complexity (sounds like a missed business opportunity), a To-Do app is a wide-open door to important questions around code architecture, component boundaries, event handling, state management, styling, testing, etc. and that’s before you even start to get into features beyond the basics of “as a busy person I’d like to be able to store tasks I need to get done” and “as a productive person I’d like to take tasks I’ve completed off the list”. If this camp is for you, welcome to orientation!

To get started, I’ll be honest, getting deep and learning all there is to know about the subjects touched on throughout this series is what Googling things is for. Go ahead, I’ll wait... (Jeopardy theme song plays..) Because of that, rather than try to position myself as THE expert or this post as THE final word on any of these things, I was serious when I said that I am more interested in entering into a conversation about the problems/solutions that jumped out at me when recently revisiting the idea of writing a To-Do app. Join the conversation in the comments below (they’ll be waiting for you after each and every installation of this series) when you’ve finished reading, or, if it’s your thing, take the conversation onto the Twitters.

The Long Game

"I wanna be the very best! Like no one ever"... wait, who am I kidding? I wanna be just like the engineers I follow on Twitter. They care deeply about making the web look good, fight to help the web work together, focus on a11y, never test the implementation details, write the best libraries, are also sometimes designers, and much, much more. That means I have to do all those things too, right? Well, luckily, no. But, that doesn’t mean I don’t spend a disproportionate part of my time trying. This means that while I’ve already written the amazing 34 line To-Do app featured above, as well as this other amazing To-Do app as a port from other popular front end technologies directly to LitElement, I feel an undeniable urge to do more, do it again, do it better, and then annoy the world by talking about it.

You are welcome!

To that end, the list of to-dos that I have for my To-Do app, this time around, looks as follows:

• component based code architecture
• custom property based style API
• event-based state management
• style sharing
• unit testing
• web component-based UI

Hopefully, these areas are all concepts that you also find interesting, and you what follows proves useful as you assess the technical decisions that go into your next application. If not, feel free to complain about it in the comments below...I love comments. What’s more, if you think I’ve left out any major points that you want to suggest I add herein or discuss in a later post, leave a comment for that, too!

There is one hot button front end engineering technique that you may have noticed is missing from the above and that’s “style encapsulation”. I left this out for good reason. Beyond it being a hotbed of disagreement across the community, due to the separate decision to make my UI with web components (with which I enjoy using Shadow DOM), I get style encapsulation for free. That means there’s no need to discuss if/how/when I’ll encapsulate my styles, they just are from the get-go. In that I don’t actually do anything to get that encapsulation, I’ve omitted it from my To-Do app’s to-do list...

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.

WestbrookJ

@westbrookj

So, I'm writing a blog post... I've noticed that while I wasn't looking it's gotten rather long, like maybe 7000 words once complete. I'd like to say I will have much luck editing it down, but some skills I'm still developing... What should I do?

12:22 PM - 20 Feb 2019

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 (you are here)
• Getting Started
• 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?
• Separate Things Early, Often, and Only as Needed (Clearly I didn’t follow this one when writing this series as a single article to start with...)
• 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!