Initial data, server side templates and linting

[m-allanson]

I've recently been using Alpine to build a Shopify theme. I've been using this pattern for my Alpine components and thought I'd share in case anyone else finds it useful.

Goals:

• Use the Shopify backend (Liquid templating tags) to supply initial data values
• Write single file "components". All HTML, CSS and JS for a piece of functionality is contained in one .liquid file
• Enable linting and formatting for JavaScript
• No build step

The pattern I reached was to use two script tags.

The first script is as short as possible, and contains any needed backend templating tags. I have a custom eslint directive eslint-skip-chunk that disables eslint parsing for the script.

As an aside - the custom eslint-skip-chunk directive is because eslint's eslint-disable is not enough. When using eslint-disable eslint will still try to parse the code, whether there are rules to apply or not. It'll throw parse errors when it finds a Liquid template tag in place of valid JavaScript.

The second script is plain JavaScript (no backend template tags) that can be linted and formatted.

Here's an example. The first <script>:

<script>
  /* eslint-skip-chunk */
  /* The above comment disables eslint for this entire script tag */
  /* Note that {{ }} and {% %} are Liquid template tags, not valid JS */
  
  window.__initialData = {
    items: [
      {%- for item in cart.items -%}
        {
          variantId: {{ item.variant_id }},
          finalPrice: {{ item.final_price }},
          quantity: {{ item.quantity}}
        },
      {%- endfor -%}
    ],
    subTotal: {{ cart.total_price }},
  };
</script>

The second script contains the component code and has __initialData spread into it:

<script>
  function cartForm() {
    return {
      ...window.__initialData,
      minOrderValue: 2000,
      handleFormChange($event) {
      	// more code here
      }
    }
  });
</script>

I've used Tailwind for the CSS, which means all the styling is applied as classes on the HTML elements. This is how the write single file components goal is handled for CSS. Tailwind slightly breaks the 'no build step rule'. But as you can use the Tailwind dev build during development, it's not too bad.

I'd be interested to hear if anyone has used a similar pattern. Thanks!

[HugoDF]

👍 I use a similar approach with Eleventy and Alpine with the 2 separate script tags (one for the data, one for the function), see https://github.com/HugoDF/alpinejs-playground/blob/master/pages/index.njk#L138-L155

[m-allanson]

That's great to see, thank you. It's good to know it's a reasonable pattern.

On the eslint side, I wanted to ensure my code is compatible with my target browsers. Normally a bundling step would take care of that.

A bit of experimenting lead to using browserslist with eslint-plugin-compat and es-compat. This willl check used language features and browser APIs against a set of supported browsers. This makes for a nice extra safety net when writing unbundled code.

[m-allanson]

A little follow up on this. I used the technique above, and it worked quite nicely. But if I were to do things again, I'd probably change things a little.

What worked well was being able to include a single liquid template, and everything just working.

The tradeoff is that it makes it harder to use any tooling that expects JavaScript to live in a .js file.

In future I'd keep the separate "liquid js" and "plain js", but with the plain js in a separate .js file. This makes it much easier to use things like prettier, eslint, esbuild etc. At the expense of a bit more effort putting the right files in the right places.

[alexantom]

@m-allanson interested to know your progress of using alpinejs in shopify theme, I'm looking for using alpinejs in Shopify 2.0 version.

Also looking into how to organize and manage reusable functions within the theme, and if we need to bundle and codesplit the js files.

This an example repo I'm currently referring https://github.com/polidario/Elizabeth

Have you come across any challenges?