Hey there,
I want to open up the frontend discussion, it’s been already around for some time and I think there is no need to argue that it’s time to make a plan in what direction we want to proceed.
That for I’d like to collect some proposals and arguments here and have a informed decision making at the next meetup.
What requires improvement?
From a developers perspective:
- It’s difficult to modify interactive UI element’s without breaking things
- Bootstrap v2 requires less-css which breaks on ruby3.1 (probably workarounds possible, but is it worth it?)
- JQuery not the state of the art anymore?
- interactive UI elements aren’t easy reusable
From a users perspective:
- usage on mobile devices
- some views are overloaded
- some views are too technical and not very intuitive to use
Things to consider
- Architecture Decision (Monolith, API + Frontends, …)
What fit’s best to our distributed development process? In the history of foodsoft there’s been often fork’s with customization for a local foodcoop. - Is there a common Programming Language / Framework in the foodsoft community? Is it easy to pick up for new contributors?
- How can we transition to a new frontend applicable to our development capacity?
Proposals
I’ve picked up some Architecture proposals I found in previous discussions for inspiration. There might be more.
1. pure Rails-based like it is now:
in my experience it is harder to make interactive interfaces while keeping a clean codebase. But it is the most straightforward approach, if you’re familiar with Rails.
Rails 7 introduces stimulus, I haven’t used it very much yet, but it looks interesting as a candidate to replace jquery. This might be the minimalist and the most “rails” approach.
To achieve the UI Component part, we could have a look at viewcomponents, also I do not have experience with that. Transitioning might be possible incrementally, converting one view after another.
2. Javascript components served from Rails views, using session authentication with non-API endpoints
that route is open and similar to 1.
framework 7 / svelte could be a technological answer to that. Also no experience with that, but it seems to be very popular at the moment.
3. Javascript components served from Rails views, using the API
this would use access tokens (which could be fetched using the OAuth dance, or generated from within Foodsoft directly; alternatively the Foodsoft session could be used, but I’d not favour that). It can be developed and run separately from Foodsoft.
4. Mini-apps using the API
a full-fledged app like foodsoft-shop, like 3 but then with their own layout (which would be candidate to make an npm module of). These can easily be run standalone, connected to an existing Foodsoft instance (perhaps ideally we’d make component out of it, allowing both embedded and standalone usage).
As seen in Foodsoft-shop PR - Plugin Integration Issue - in use plugin .
I think this is a great approach to fulfill different needs from the community and fits a distributed development approach. Quite some effort went into the API design and Foodsoft-Shop is a working example for this.