DEV Community: Daniel Vivar

Here's a minimalist no-frills Redux Toolkit & LitElement example

Daniel Vivar — Sun, 21 Feb 2021 10:11:29 +0000

Picture by @16pxl

Tired of full boilerplate Redux examples? What about all the Redux Toolkit examples that try to explain how much complexity is now reduced into opinionated functions... based on your knowledge of Redux?

I believe it's the most minimalist examples based on the simplest systems which tell you all.

The way to build a complex system that works is to build it from very simple systems that work.
— Kevin Kelly

Here I present you a simple system of a Redux Toolkit store and two LitElement based Web Components.

The Components

Our system is based on 2 components: one to control a variable and another one to show the state of the variable. As simple as it can get.

Of course you won't use Redux Toolkit to do that if you have just 2 components, but that's not why you're here, isn't it?

I've called them auth-control and auth-info, it's a dumb system to sign in and sign out just by clicking on buttons that say "Sign in" and "Sign out". See? No frills as promised 😂

`<auth-info>`

This component just shows a salute if you're signed in, based on an isAuthenticated property.

import { LitElement, html } from 'lit-element'

class AuthInfo extends LitElement {

  static get properties() {
    return {
      isAuthenticated: Boolean,
    }
  }

  render() {
    if (this.isAuthenticated) {
      return html`
        <p>Hi, you're signed in</p>
      `
    }
  }
}

window.customElements.define('auth-info', AuthInfo);

`<auth-control>`

Here's the controlling component. As you can see, they have a property with the same name: isAuthenticated.

import { LitElement, html } from 'lit-element'

class AuthControl extends LitElement {

  static get properties() {
    return {
      isAuthenticated: Boolean
    };
  }

  handleSignIn () {
    this.isAuthenticated = true
  }

  handleSignOut () {
    this.isAuthenticated = false
  }

  render() {
    if (this.isAuthenticated) {
      return html`
        <button @click=${this.handleSignOut}>Sign Out</button>
      `
    }
    return html`
      <button @click=${this.handleSignIn}>Sign In</button>
    `
  }
}

window.customElements.define('auth-control', AuthControl)

The Store

The goal is to share the state of the property isAuthenticated from a global state store. We will use Redux Toolkit to accomplish that:

import { createSlice, configureStore } from '@reduxjs/toolkit'

const { actions: authActions, reducer: authReducer } = createSlice({
  name: 'isAuthenticated',
  initialState: false,
  reducers: {
    signIn: () => true,
    signOut: () => false
  }
})

const { signIn, signOut } = authActions

const store = configureStore({
  reducer: {
    isAuthenticated: authReducer
  }
})

export { store, signIn, signOut }

Note the neat use of destructuring to obtain all the necessary information from createSlice. If you want to add more data to the store: just create a new slice, add the obtained reducer to the list of reducers to feed to configureStore and export the actions so that your app can update the state.

The connection

Now we need to connect the store with both components. In order to do that we'll use a connect mixin from Polymer project pwa-helpers.

This mixin will add logic to our component that will end up calling stateChanged every time the state changes, so to complete the connection we have to implement this callback function as well.

Connecting `<auth-info>`

...
import { connect } from 'pwa-helpers'
import { store } from './state.js'

class AuthInfo extends connect(store)(LitElement) {
...
  stateChanged(state) {
    this.isAuthenticated = state.isAuthenticated;
  }
...

That's it. You don't even need a constructor, as the store dispatches the initial state on connection.

Connecting `<auth-control>`

...
import { connect } from 'pwa-helpers'
import { store, signIn, signOut } from './state.js'

class AuthControl extends connect(store)(LitElement) {
...
  stateChanged(state) {
    this.isAuthenticated = state.isAuthenticated;
  }

  handleSignIn () {
    store.dispatch(signIn())
  }

  handleSignOut () {
    store.dispatch(signOut())
  }
...

Same here, plus we imported the actions to dispatch when handling the events for the sign in and sign out buttons.

Final touches

An HTML page to hold the components together and a build process to resolve the dependencies for LitElement and others is all you might need. We're using Snowpack for that.

Buildless anyone?

You could perfectly use packages from a CDN like Skypack or UNPKG and skip the build process altogether if you fancy. Like so:

-- import { LitElement, html } from 'lit-element'
++ import { LitElement, html } from 'https://cdn.skypack.dev/lit-element'

Having a well thought buildless process have great benefits. In fact, Snowpack has an option to do just something like we just did there, using CDN packages instead of installing them manually. It's called Streaming Imports in case you're interested 😉.

Complete example

Please dig in the whole example I've done for you in Glitch. Feel free to remix it there and leave feedback in the comments 👇 Any question or comment will be welcome!

Resetting styles inside Lit-Element Web Components

Daniel Vivar — Sat, 30 Jan 2021 23:46:18 +0000

Photo by Michele Blackwell on Unsplash

So you are working on your Web Components and soon enough you realize they are really good at encapsulating stuff. That's the goal. Check out this Web Component:

There are 2 p tags. On the one hand, we have one declared entirely inside the Web Component, the one with inner content:



...
render() {
  return html`
    <div>
      <p>Inner content</p>
    </div>
    <div>
      <slot></slot>
    </div>
  `
}
...

And on the other hand, we have a p tag declared as part of the body which is moved in as part of the slot functionality of our Web Component:



...
<div>
  <my-element>
    <p>Slotted content</p>
  </my-element>
</div>
...

We have a reset rule declared for p tags:



p {
  margin: 0;
}

As you can see, the p tag declared outside gets the style applied and moved in without margins. However the p declared inside is "protected" from the page styles and so it gets general treatment: user agent styles. That's why they look different.

How do we solve this problem?

So far, I think there's only one way to solve it: declaring the reset styles within the Web Component as well. In our Web Component, the styles static class getter will looke like so:



static get styles() {
  return css`
    div {
      border: 1px solid red;
    }
    p {
      margin: 0;
    }
  `;
}

Here is our updated pen:

Solved, right? Well, it works, but this is far from optimal. Firstly, we should have this reset styles outside the Web Component itself, that way you can share the reset styles amongst other components. Something like this:



...
const resetStyles = () => css`
  p {
    margin: 0;
  }
`
...
static get styles() {
  return [
    resetStyles(),
    css`
      div {
        border: 1px solid red;
      }
    `
  ]
}
...

But secondly and more importantly, as a good rule of thumb in software development: never have the same stuff repeated.

We still have a reset styles stylesheet, let's call it reset.css, and an object with the reset styles which is returned by resetStyles(). That means we have the reset styles both as a LitElement's css object and as an independent stylesheet.

The cool thing would be to have the reset stylesheet and that's it.

How do we do that?

We can process the stylesheet and create a CSS object, just how LitElement understands them. There are many ways to do this, I'll use Rollup for my example.

Let's Rollup! Using a simple config like this:



import litcss from 'rollup-plugin-lit-css'

export default {
  input: 'src/reset.css.js',
  plugins: [
    litcss({ uglify: true })
  ],
  output: {
    file: 'reset.css.lit.js',
    format: 'es'
  }
}

Here we're using Rollup's great rollup-plugin-lit-css plugin by

Benny Powers 🇮🇱🇨🇦Follow

Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git. *Opinions posted are my own*

Our src/reset.css.js is super simple:



export { default } from '../reset.css'

That's it!

Now we can use it in LitElement:



...
import reset from "./reset.css.lit.js";
const resetStyles = () => reset
...

We'll need something more advanced than CodePen for this, let's use Glitch and voilá! Now we only have one place where our reset styles are written (reset.css). Check it out:

Remember in this example the file reset.css.lit.js has been created by Rollup.

Minireset.css

A similar approach than the one just explained I used to improve minireset.css in this PR and provide an additional LitElement compatible file other people can use in LitElement Web Components. minireset.css is a great (and very tiny) reset you can use at production sites, which I recommend, check it out:

https://jgthms.com/minireset.css/

Install it on your project:



npm install --save minireset.css

Then in LitElement Web Components where you want to have the styles reset, import them:



import { minireset } from 'minireset.css/minireset.css.lit.js'

And then either use them as part of an array CSS result, like so:



static get styles() {
  return [
    minireset,
    ... your other styles
  ]
}

or directly in your styles:



static get styles() {

  return css`

    ${minireset}

... your other styles



`

}

That's a wrap!

I hope you found this article useful. Questions and feedback are very welcome 🙂

All the ways you can build a web based on content (IV)

Daniel Vivar — Sat, 30 Jan 2021 21:27:46 +0000

Photo by Joaquim Campa

In Part III we were talking about static servers being cheap... or even free! Here's a curated list of providers you can use:

https://serverless.css-tricks.com/services/hosting

How to use hosting static servers like those and still being able to neatly separate the data from the website itself?

Solution 3: Static Site Generator

With an SSG, you will mix up data with templates to obtain a fully static site. This is exactly how some CMSs work indeed. Compared with SSR (discussed in Part II), the main advantage is that the processing of data is moved outside the web server. Let's see how our FruitLovers site would look now and we will discuss later about who should choose this approach.

For this stack we will be using a grrrrreat SSG called Eleventy. Eleventy can digest all kinds of template engines, but for our example we will be using Nunjucks by Mozilla.

Our data will be the same, as always. That's also the beauty of it. You can keep the data, change the way you process and create the website out of it, and the end product would look the same to a visitor.

[
  {
    "name": "lemon",
    "title": "Lemons, our classic",
    "price": "2€",
    "image": "images/lemon.jpg"
  },
  {
    "name": "strawberry",
    "title": "Strawberries, less sugar than lemons!",
    "price": "3€",
    "image": "images/strawberry.jpg"
  }
]

In Eleventy, if we save this in _data/fruits.json it will be available directly as a collection we can iterate over on our templates.

The main layout template is as you would expect:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>{{title}}</title>
    <style>
      {% include 'styles.css' %}
    </style>
  </head>  
  <body>
    <header>
      <h1>🍋 FruitLovers</h1>
      <p>
        If life gives you lemons... 
      </p>
    </header>

    {{ content | safe }}

    <footer>
      FruitLovers © 2021
    </footer>
  </body>
</html>

The title will be replaced at {{ title }}. And the content fed to this template will be replaced in {{ content | safe }}.

The pipe | is an operation to input in safe the output of content so that HTML characters are not escaped. We did something very similar when we were using the Handlebars template engine in part II. Then we were using 3 curly braces instead of 2, remember? It's the same idea 🙂
Read this for more info about double escaping in layouts: https://www.11ty.dev/docs/layouts/#prevent-double-escaping-in-layouts

If we save it in _includes/layouts/default.njk then we can use it directly by name, like in the template for our home page:

---
layout: layouts/default
title: "FruitLovers - Home"
---
<main>
  <h2>
    Fruits you can buy from us
  </h2>
  <ul>
    {% for fruit in fruits %}
      <li>
        <a href="/products/{{ fruit.name }}.html">
          {{ fruit.title }}
        </a>
      </li>
    {% endfor%}
  </ul>
</main>

Here we are using a Nunjuck's tag called for. fruits represent the array of fruits from the _data/fruits.json defined before. We can declare a name for the unit, fruit so it's easier to read. This looks like a super neat way to create lists, doesn't it?

Our product page is a bit more tricky. Remember we have to remove the actual fruit from the list of fruits: we called this list restOfFruits. Here, instead of creating a new list with the fruit removed, we're using a Nunjuck's tag called if. And inside the loop of fruits, only proceed if our fruit and list item in the loop is different. We're using Eleventy's page.url to know which fruit the actual page is for.

In this case, in order to create pages out of all the fruits, we will be using Eleventy's pagination feature. See more Eleventy's pagination here:
https://www.11ty.dev/docs/pagination/

Here's how our product page template would look using Eleventy's pagination:

---
layout: layouts/default
tag: product
pagination:
    data: fruits
    size: 1
    alias: fruit
permalink: "products/{{ fruit.name }}.html"
eleventyComputed:
  title: FruitLovers - {{ fruit.title }}
---

<main>
  <a href="/index.html">← Home</a>
  <h2>
    {{ fruit.title }}
  </h2>
  <p>
    Today's price is: {{ fuit.price }}
  </p>
  <img width="300" src="{{ fruit.image }}">
  <h2>
    Other fruits you can buy from us:
  </h2>
  <ul>
    {% for fruit in fruits %}
      {% if not page.url.includes(fruit.name) %}
        <li>
          <a href="/products/{{ fruit.name }}.html">
            {{ fruit.title }}
          </a>
        </li>
      {% endif %}
    {% endfor %}
  </ul>
</main>

Now here's the end result in Glitch:

Using an SSG such as Eleventy is a 2-part process. First we create the site, and secondly we upload it to our static server. In my Glitch example, this is the start script:

"start": "eleventy --serve --input=src --output=_site"

That means we're creating the site out of the data in src and outputting it at _site.

By the way, have you noticed whatever is being created in _site is exactly the same code we had in our Part I example made out only with HTML & CSS?

We're also serving it directly with --serve, which is OK for when we're in development mode. The second part of the process involves copying the _site folder to your static server, wherever that might be. That's where you should use the hosting static servers I linked at the beginning of this article!

SSG is a great solution when your data seldom changes and the number of pages is reduced. If you wanted to manage a site like Amazon with an SSG, you would have to process most of the pages continuously, which is far from optimal.

Most small sites like restaurant websites would be a great fit for SSG.

I hope you enjoyed this series of articles as much as I did writing them for you.

I'll answer any question promptly and feedback of any kind is welcome.

Thanks for reading.

All the ways you can build a web based on content (III)

Daniel Vivar — Wed, 27 Jan 2021 23:03:11 +0000

Photo by Joaquim Campa

Solution 2: Single Page Applications

The main feature of an SPA is its router implementation: so that you can keep one page and never reload.

Let's make an SPA for our FruitLovers store. Famous SPA frameworks include React, Vue.js and Angular. However I'm really down to keep our examples as close to web standards as possible so we'll be using Web Components, helped by a router called Vaadin Router.

If you're not familiar with Web Components, this introductory guide from MDN Web Docs is quite nice:
https://developer.mozilla.org/en-us/docs/Web/Web_Components

With this example we will enter the realm of JavaScript and client scripting for the first time. Our main and only page will look like this now:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>FruitLovers - Home</title>
    <link rel="stylesheet" href="styles.css">
  </head>  
  <body>
    <header>
      <h1>🍋 FruitLovers</h1>
      <p>
        If life gives you lemons... 
      </p>
    </header>
    <main id="app">
      Loading...
    </main>
    <footer>
      FruitLovers © 2021
    </footer>
    <script src="app.js" type="module"></script>
  </body>
</html>

Now the magic will happen at app.js, and the <main id="app"></main> element is where our router will be attached. We'll see that later on.

First, the data, unchanged, just as we had it before:

[
  {
    "name": "lemon",
    "title": "Lemons, our classic",
    "price": "2€",
    "image": "lemon.jpg"
  },
  {
    "name": "strawberry",
    "title": "Strawberries, less sugar than lemons!",
    "price": "3€",
    "image": "strawberry.jpg"
  }
]

Now let's define a couple of helper functions to help us with the fruits list:

// This returns a <li> element based on a fruit object
function getFruitItemHTML({ name, title }) {
  return `<li><a href="/products/${name}.html">${title}</a></li>`
}

// This returns a <ul> element based on a fruits list array
export function getFruitsListHTML(fruitsList) {
  return `<ul>${fruitsList.map(getFruitItemHTML).join('')}</ul>`
}

Vaadin Router is specifically designed with Web Components in mind, where each route is managed by a single Web Component. As we've seen from the beginning, we have two types of pages, home and product pages, so we will only need two Web Components.

Making use of our helper function by importing it, let's define the Web Component for our home:

import { getFruitsListHTML } from '../lib/getFruitsListHTML.js'

export function defineFlHome(fruits) {
  customElements.define('fl-home',
    class extends HTMLElement {
      connectedCallback() {
        document.title = 'FruitLovers - Home'
        this.innerHTML = `
          <h2>
            Fruits you can buy from us
          </h2>
          ${getFruitsListHTML(fruits)}
        `
      }
    }
  );
}

It's basically a header and a list of our products. In a similar fashion, let's define the Web Component for our product:

import { getFruitsListHTML } from '../lib/getFruitsListHTML.js'

export function defineFlProduct(fruits){
 customElements.define('fl-product',
    class extends HTMLElement {
      connectedCallback() {
        const requestedProductName = this.location.params.product
        const restOfFruits = fruits.filter(({name}) => name !== requestedProductName)
        const requestedProduct = fruits.find(({ name }) => name === requestedProductName)
        document.title = `FruitLovers - ${requestedProduct.title}`
        this.innerHTML = `
          <a href="/index.html">← Home</a>
          <h2>
            ${requestedProduct.title}
          </h2>
          <p>
            Today's price is: ${requestedProduct.price}}
          </p>
          <img width="300" src="${requestedProduct.image}">
          <h2>
            Other fruits you can buy from us:
          </h2>
          ${getFruitsListHTML(restOfFruits)}
        `
      }
    }
  ) 
}

This gets a bit more complex since we need a modified list of fruits, taking out the actual fruit we're seeing. this.location.params is provided by the router in this case (See #accessing Route Parameters in the Vaadin Router docs).

Lastly, our router at app.js will look like this:

import { Router } from 'https://unpkg.com/@vaadin/router'
import { defineFlHome } from './components/fl-home.js'
import { defineFlProduct } from './components/fl-product.js'

fetch('/data.json')
  .then(_ => _.json())
  .then(fruits => {
    defineFlHome(fruits)
    defineFlProduct(fruits)
  })

const appContainer = document.getElementById('app')
appContainer.innerHTML = ''
const router = new Router(appContainer)

router.setRoutes([
    { path: '/(index.html)?', component: 'fl-home' },
    { path: '/products/:product.html', component: 'fl-product'},
  ]);

Note how the process to fetch the data is asynchronous, in this implementation: only after loading the fruits we define the UI of each page/component through its Web Component definition.

Also note how we've implemented a very basic loading state. Remember initially the home page has this as its main content:

<main id="app">
  Loading...
</main>

So the user will see this up until the router loads the actual content.

The final result loads pages instantly, just as promised, voilá!

OK, so far we've seen pages been produced at servers with Server Side Rendering in Part I. As we've seen SSR involves great complexity at the server level.

In Part II we've seen Single Page Applications. Here the pages are managed by a router running in the client's browser. In SPAs the meaning of a "page" gets diluted in... routes? SPAs are great when the content is specific to the visitor: a bank, a social network... anywhere where you need to sign in and authenticate!

What if you just want a website with "real" pages like in our very basic first example served by a static server? Amongst the list of reasons to prefer this is SEO (Search Engine Optimisation). Also static servers are cheaper... or even free!

Head on to part IV...

All the ways you can build a web based on content (IV)

Daniel Vivar ・ Jan 30 '21 ・ 4 min read

All the ways you can build a web based on content (II)

Daniel Vivar — Wed, 27 Jan 2021 22:39:17 +0000

Photo by Joaquim Campa

Solution 1: Server-side Rendering

SSR was the first approach to CMSs, back in the 90s. With SSR, pages are created by a server, based on data which is detached from it. Either by creating the page dynamically when it is requested, or producing them beforehand and store it in a cache.

With the aim to keep simple examples and not deviate much from HTML, CSS & JavaScript, let's use Node.js technology for our server. Express, which is a Node.js web framework for servers, would do. Let's also use a template engine so that Express can focus on dealing with web requests only. Handlebars is a good simple one and works great with Express.

Let's get to it. First let's work on the main layout of all our pages. It would look like so:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>FruitLovers - {{ title }}</title>
    <link rel="stylesheet" href="/styles.css">
  </head>  
  <body>
    <header>
      <h1>🍋 FruitLovers</h1>
      <p>
        If life gives you lemons... 
      </p>
    </header>
    {{{ body }}}
    <footer>
      FruitLovers © 2021
    </footer>
  </body>
</html>

This will be used as the default template for the Handlebars template engine in Express, where they're called views. In this template, the page content will will be replaced in {{{ body }}}. The title of the page will be replaced in {{ title }}.

In Handlebars syntax, three curly braces won't scape HTML characters, but two will. More info here about what that means:
https://handlebarsjs.com/guide/#html-escaping

The home page specific content will look like so:

<h2>
  Fruits you can buy from us
</h2>
<ul>
  {{#each fruits}}
    <li>
      <a href="/products/{{name}}.html">
        {{title}}
      </a>
    </li>
  {{/each}}
</ul>

Notice how we've used a Handlebars built-in helper called #each. In our example, this helps when defining the list of fruits.

The product's template will be very similar:

<a href="/index.html">← Home</a>
<h2>
  {{fruit.title}}
</h2>
<p>
  Today's price is: {{fruit.price}}
</p>
<img width="300" src="{{fruit.image}}">
<h2>
  Other fruits you can buy from us:
</h2>
<ul>
  {{#each restOfFruits}}
    <li>
      <a href="/products/{{name}}.html">
        {{title}}
      </a>
    </li>
  {{/each}}
</ul>

As you can see it's just about separating the data from the page and pulling only what you need. From the example, we can gather the data, in data.json:

[
  {
    "name": "lemon",
    "title": "Lemons, our classic",
    "price": "2€",
    "image": "images/lemon.jpg"
  },
  {
    "name": "strawberry",
    "title": "Strawberries, less sugar than lemons!",
    "price": "3€",
    "image": "images/strawberry.jpg"
  }
]

Now let's work on our server: the process that will manage the web requests. I'm commenting every line to help understand the code:

// Import Express and create an app
const express = require("express");
const app = express();

// Import fruits data
const fruits = require('./data.json')

// Tell express that views are in the views folder
app.set('views', 'views');
// Tell express to use handlebars template views
app.set('view engine', 'hbs');

// Serve public folder as static
app.use(express.static("public"));

// Manage requests to the index
app.get(["/","/index.html"], (request , response) => {
  // Use the index view, passing the data it needs for fruits and title
  response.render('index', { fruits, title: 'Home' });
});

// Manage requests to product pages
app.get("/products/(:product).html", (request, response) => {
  // Get requested product from URL
  const requestedProduct = request.params.product
  // Get info about the fruit which corresponds to the requested product name
  const fruit = fruits.find(({name}) => name === requestedProduct)
  // Remove the requested product from the list of fruits
  const restOfFruits = fruits.filter(({name}) => name !== requestedProduct)
  // Use the product view, passing the data it needs
  response.render('product', { fruit, restOfFruits, title: fruit.title });
});

// Start listening for requests :)
const listener = app.listen(process.env.PORT, () => {
  console.log("Your app is listening on port " + listener.address().port);
});

Please, take a look to the final version on Glitch, browse the /views folder and the package.json file to see how the server is set up. Click on View Source and View App to switch between panes without moving from here ;)

Please note all of the code in this series of articles is far from production-ready. Also, not written out for performance either. What if a visitor requests the non-existing orange product? What if the price is missing in the data? Is it performant to run through all the fruits twice (as seen in our code) for every server request? Etc.

SSR is great whenever you have tons of non-personal data which will produce thousands of pages, such as Amazon. It also requires a specific type of web server, which is more expensive than a static server.

Did you notice how every click required a full reload? That's how the web works by design!

A considerable group of people wanted to improve this experience, making it smoother: what if we only load the page once? What if JavaScript code inside that page manages the page routes from the client's browser and load only the parts of the page that change?

Head on to part III...

All the ways you can build a web based on content (III)

Daniel Vivar ・ Jan 27 '21 ・ 4 min read

All the ways you can build a web based on content (I)

Daniel Vivar — Wed, 27 Jan 2021 22:28:12 +0000

Photo by Joaquim Campa

Intro

After many years working on CMSs (Content Management Systems) and creating websites for myself and others, I have come to understand that the basic problem all website owners have is:

How to go from data to working websites?

I'll try to answer to that question through the examples on this series of articles.

Of course, everything could get very complex, very fast. Data could come in many flavours and sizes. And the website could be a fully interactive complex app, such as Facebook, Amazon or Netflix... or as simple as your regular Joe's Restaurant. I'll try to keep the complexity to a bare minimum, so you can understand for yourself how the inner technologies work.

The one thing you need to know though: there's not a single solution to solve all these websites' needs. I hate reading myself saying this but in this particular case, how to go from your data to your website? It really depends...

Basic example

Let's start with the basics and create an example website we can use as a starting point. A fruit store called FruitLovers with 2 products: lemons and strawberries. That's 3 pages: one page as home/index page which will list the fruits, and one for each fruit, like so:

- index.html   
- products/
    - lemon.html
    - strawberry.html

The basic structure of our HTML web pages would be:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Title of page</title>
  </head>  
  <body>
    ... 
  </body>
</html>

Simple, no? Let's add a header to all our pages:

<header>
  <h1>🍋 FruitLovers</h1>
  <p>
    If life gives you lemons... 
  </p>
</header>

And a footer as well:

<footer>
  FruitLovers © 2021
</footer>

Now the main content of our home page:

<main>
  <h2>Fruits you can buy from us</h2>
  <ul>
    <li>
      <a href="products/lemon.html">
        Lemons, our classic
      </a>
    </li>
    <li>
      <a href="products/strawberry.html">
        Strawberries, less sugar than lemons!
      </a>
    </li>
  </ul>
</main>

Now blending everything together, here's the HTML structure for our home page:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>FruitLovers - Home</title>
  </head>  
  <body>
    <header>
      <h1>🍋 FruitLovers</h1>
      <p>
        If life gives you lemons... 
      </p>
    </header>
    <main>
      <h2>
        Fruits you can buy from us
      </h2>
      <ul>
        <li>
          <a href="products/lemon.html">
            Lemons, our classic
          </a>
        </li>
        <li>
          <a href="products/strawberry.html">
            Strawberries, less sugar than lemons!
          </a>
        </li>
      </ul>
    </main>
    <footer>
      FruitLovers © 2021
    </footer>
  </body>
</html>

Let's get to our lemon page. All the structure, plus the same header and footer will be there. Let's add a title, price and an image:

<main>
  <h2>
    Lemon
  </h2>
  <p>
   Today's price is: 2€
  </p>
  <img src="images/lemon.jpg" />
</main>

We should have a way to go back to our home page 😅. Let's add a link to go back:

<main>
  <a href="index.html">
    ← Home
  </a>
  <h2>
    Lemon
  </h2>
  <p>
   Today's price is: 2€
  </p>
  <img src="images/lemon.jpg" />
</main>

It would also be nice if we show the list of other products in each fruit's page, like so:

<main>
  <a href="index.html">← Home</a>
  <h2>
    Lemon
  </h2>
  <p>
    Today's price is: 2€
  </p>
  <img src="images/lemon.jpg">
  <h2>
    Other fruits you can buy from us:
  </h2>
  <ul>
    <li>
      <a href="products/strawberry.html">
        Strawberries, less sugar than lemons!
      </a>
    </li>
  </ul>
</main>

To have something more palatable, let's add some basic style in a CSS file too:

- index.html   
- products/
    - lemon.html
    - strawberry.html
- styles.css 👈

html {
  font-family: sans-serif;
}

And add it to all pages with a link tag in the head:

...
<head>
   ...
   <link rel="stylesheet" href="/styles.css">
</head>

This is the end result:

The technology needed for a website like this? A pretty basic static web server, cheap (mostly free!), reliable and compatible with anything that reads HTML.

In this example, the input and the output are on the same place. The website itself is where the content is.

Think about all the things that need to be done just to add another product. You will need to:

create a new page, following the same design/pattern;
add it to the list in the homepage;
and add it to the list of all the products' "Other fruits" lists.

So many places, and so easy to commit a mistake! 😅

What if you want to change the design or structure of any of the pages, or if you want to change the header or footer, and the same goes if you want to add an analytics script. In all these case you'll have to edit all pages!

A solution like this is OK for a website owner with limited resources, where you can count all the pages with one hand.

However, I think it's clear to say there are already lots of things that are repeated in our website. The header and footer are repeated all over. The fruit product pages are really similar, only differing in the specific data of each fruit. For maintainability, we should only write things once and keep the data somewhere else.

How do we solve this problem?

... head on to part II

DEV Community: Daniel Vivar

Here's a minimalist no-frills Redux Toolkit & LitElement example

The Components

<auth-info>

<auth-control>

The Store

The connection

Connecting <auth-info>

Connecting <auth-control>

Final touches

Buildless anyone?

Complete example

Resetting styles inside Lit-Element Web Components

How do we solve this problem?

Benny Powers 🇮🇱🇨🇦Follow

Minireset.css

That's a wrap!

All the ways you can build a web based on content (IV)

Solution 3: Static Site Generator

All the ways you can build a web based on content (III)

Solution 2: Single Page Applications

All the ways you can build a web based on content (IV)

Daniel Vivar ・ Jan 30 '21 ・ 4 min read

All the ways you can build a web based on content (II)

Solution 1: Server-side Rendering

All the ways you can build a web based on content (III)

Daniel Vivar ・ Jan 27 '21 ・ 4 min read

All the ways you can build a web based on content (I)

Intro

Basic example

How do we solve this problem?

All the ways you can build a web based on content (II)

Daniel Vivar ・ Jan 27 '21 ・ 4 min read

`<auth-info>`

`<auth-control>`

Connecting `<auth-info>`

Connecting `<auth-control>`