How do you use AlpineJS in your project?

[egkrly]

I would like to start this thread to educate myself on the use-cases of Alpine by other people.

Feel free to answer any of the questions that I listed below, no need to answer all if don't want to.

Questions

• Why Alpine? For how long are you using it?
• What is your overall technology stack? (including test frameworks for Unit, E2E)
• What are the characteristics of your website? (SSR, content type, etc)
• How do you organize your Alpine code? (Leaving all Alpine logic in template? Have JS/TS files for your components?)
• What challenges you face, or faced while interacting with Alpine?
• What do you like about Alpine?

I will start.

Why alpine?

• My team almost a year ago has decided to use Alpine on a mid-size project of ours.
• Our content is mostly rendered on the server side, we don't have much JS logic going on, so using React would have been an overkill.
• We wanted a framework that gives us the possibility to create FE templates on the server side .
• Transitioning was also important, we inherited a legacy codebase, and moving to a popular modern framework (eg. NextJS) would have been too costly.

Technology stack

BE: Python, Flask, Jinja
FE: Alpine, Typescript, HTMX, TailwindCSS
Testing: Jest, Playwright, Flask template tests

Code organization

• We aim to put our business logic in TS files, HTML templates are only for handling UI events, displaying data, etc.
• We use JS classes to create our Alpine.data and Alpine.strore components.
• We use Jinja macros to split up our components to smaller chunks.

Challenges

• We use classes to declare our Alpine components. We do this because we want to separate the business logic, and we aim to cover as much of this with unit tests as possible. Using classes are also freeing us up from the duty to maintain an Interface for our object or function based components, it is way more TS friendlier this way.
  • This can be tricky at times, even the official documentation doesn't share any information about using classes. With classes, accessing and using Magic variables is tricky, we use the Alpine.Magics interface to be compatible with TS.
• Aiming for reusability is hard (let's say, a Toast component, that is a part of a bigger page-wide component).
• Testability - As said previously, we try to have our business logic in TS, and we use Classes. If we would leave eveything in the HTML templates, we wouldn't be able to unit test too much of the logic there.
• Readibility is hard (with Jinja and Alpine combined).
  • Maybe this is a personal one, I'm coming from a React background, and I'm pretty used to JSX.
• Small community - If I'm dealing with some problems, or I don't understand something then often I have to go and read the Alpine source code to understand what is happening.
• AI code completion - Copilot doesn't seem to be able to follow the Jinja - Alpine rules that mutch, it has a hard time to understand what the template is doing.

Summary

Feel free to share any of your thoughts on the matter. I'm excited about using this tool and it would be really nice to see what's the community up to, and how you guys feel about this framework so far.

[viktorHadz]

I'm very curious to know about this too. I have been using alpine as the main driver behind a spa type of app. Although I think most people use it with a backend system or templating engine.

So I'd be curious to see it used in practice by an experienced engineer.

Thanks for starting the thread.

[ekwoka]

I've been using it for 3 years now, primarily on Shopify stores (most doing $1m/month each).

Mostly end up with the component logic (data and such) in TS files that load all of them on every visit, with liquid templates handling the bindings to the UI.

I don't find reusability to be an issue at all, but of course, I've touched tons of the source code directly, and maintain the types package you probably use.

Don't really use classes, just plain objects, I'd be interested to know what specific issues you're running into with using classes (and if it's runtime or type level issues).

What issues do you find with the toast example? I've made multiple toast systems used in production with Alpine, and they've been pretty easy to get going for the use cases.

I have a WIP public Toaster package here: https://github.com/ekwoka/awesome-alpine/tree/main/packages%2Ftoasts

[egkrly]

Hello Everyone, and @ekwoka !

First of all, thanks for maintaining the project! :)

The main problem with classes was the constructor() method, and we wasn't aware of this for a long time.

I've ran Alpine locally, so I could debug how it works, and I saw that it creates Proxies over elements and Alpine components / stores.

Most of our issues came when we started doing something in the constructor; eg. adding event listeners to something, and the callback that we pass is an anonymous function that will use a different context when it's executed, than the one that Alpine is proxied after it's initialized.

This mostly resulted in a weird behaviour where the state inside class would be updated, but the template won't pick that up. But by now, we know that this was caused, because we didn't use the init() method, which is fired after Alpine has finished initializing and added it's proxies to everything.

Also, we have noticed that init() is not executed when initializing Alpine.store() with a class instance, created a bug issue for that: #4622

Other than this, everything is fine with the classes I would say. It took us some time to figure out why the constructor was causing weird behaviour sometimes.
It was also cool that we could use the Alpine magics interface, so those are available on our classes as well. (Y)

[ekwoka]

Ah yes, that does make sense. Not really anything we can do about that, unfortunately. But yes, constructor can be used to get initial state prepped, but init should be used for anything that would need reactivity.

[egkrly]

Oh, and the toast example: Haven't realised that x-data can be safely wrapped in eachother, and multiple instances can exist of them. :) It was a huge gotcha.

For some reason I assumed that Alpine would go nuts if I had a template like this:

<div x-data="form">
  <span x-text="value"></span>
  <div x-data="customInput">
    <span x-text="value"></span>
  </div>
</div>

My "fear" was that if each has value field Alpine would use some of them and it would collide, but after I started playing around with it realised it's handling it logically well.

I was also fearing a bit that it would mess up $refs and other magic stuff.