wip: semantic tables and forms

[tvdeyen]

Summary

Closes #5944

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.81%. Comparing base (dcb0dd8) to head (0d07498).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6014   +/-   ##
=======================================
  Coverage   87.81%   87.81%           
=======================================
  Files         476      476           
  Lines       11658    11658           
=======================================
  Hits        10238    10238           
  Misses       1420     1420           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tvdeyen]

@MadelineCollier @kennyadsl

Thanks for the feedback. Though.

I tested this a bit more today and I am not sure the user flow is an acceptable solution. With the new implementation we change the URL when we open the modal. This leads to weird browser history behavior. Every time the modal opens we have a point in history, which the browser goes back to if one clicks on history back. I am not sure this is desirable.

So, what we would need to do is open the modal on click and display the result from the edit route. This is exactly what we do in Alchemy and this is very successful, fast (because we do not reload the table displayed under the modal, just the form), semantic and even tests work without JS enabled.

I could port this over to Solidus, but there is much more involved, because currently the admin is build to open the modal on the edit page and redisplaying the whole table. Which is painful for performance, but this is how things are implemented and fixing that will cost more time than I am willing to invest right now.

This is a huge bummer. I would love to have been involved planning the architecture of the new admin, but we are here now and we will need to revisit this some time in the future. Probably we never will.

😞

[kennyadsl]

@tvdeyen I'd like to invest in this if we think it's the right solution. Maybe @MadelineCollier can work on that under your guidance?

[tvdeyen]

@tvdeyen I'd like to invest in this if we think it's the right solution. Maybe @MadelineCollier can work on that under your guidance?

Yes, why not. But ideally, now that Solidus has also adopted the "Forms-in-Modals"™️ UX we pioneered in Alchemy years ago, we would share a common UX library between Alchemy and Solidus (as I have proposed before). It does not make sense to solve the same exact UX problems in two Rails engines in this small niche. I also figured that the new Solidus Admin does not have a Resource Controller (yet). Alchemy has one, as well as the legacy admin. Why not share the same CRUD interface code for most resources in both engines?

There a lot of trade offs, sure (mainly CSS styling, we do not use tailwind in Alchemy). Also we do not use Stimulus in Alchemy and never will, because Stimulus is soon-to-be-legacy™️ tech. We use future proof custom elements (Web Components) w/o any framework in Alchemy.

But this can and should be solved, because we want that Stores can continue to build their admin as well, right? This is part of the Solidus (and Alchemy) success story. That they can build their own CRUD admin pages with the tools we provide.

If we would be willing to share efforts between both teams (actually they are quite similar) I am more than happy to supervise and even work on fundamentals. Maybe even add resources from my consulting company as well, as we have an interest in both engines being easy to maintain and share a common interface.

[MadelineCollier]

@MadelineCollier @kennyadsl

Thanks for the feedback. Though.

I tested this a bit more today and I am not sure the user flow is an acceptable solution. With the new implementation we change the URL when we open the modal. This leads to weird browser history behavior. Every time the modal opens we have a point in history, which the browser goes back to if one clicks on history back. I am not sure this is desirable.

So, what we would need to do is open the modal on click and display the result from the edit route. This is exactly what we do in Alchemy and this is very successful, fast (because we do not reload the table displayed under the modal, just the form), semantic and even tests work without JS enabled.

I could port this over to Solidus, but there is much more involved, because currently the admin is build to open the modal on the edit page and redisplaying the whole table. Which is painful for performance, but this is how things are implemented and fixing that will cost more time than I am willing to invest right now.

This is a huge bummer. I would love to have been involved planning the architecture of the new admin, but we are here now and we will need to revisit this some time in the future. Probably we never will.

😞

Definitely a huge bummer for this to be the outcome. 💛 I really appreciate that you took it on yourself to investigate this alternative solution though and now we know the path forward. I agree with @kennyadsl that this seems worth the effort and I'd be happy to work on this with your input and guidance as soon as I have wrapped up the remainder of the users admin.