Actions
Feature #43165
openA Roadmap for the Future of Redmine View Development
Status:
New
Priority:
Normal
Assignee:
-
Category:
UI
Target version:
-
Start date:
Due date:
% Done:
0%
Estimated time:
Resolution:
Description
A clear roadmap for the future of Redmine view development would be very helpful when considering new features or contributions.
- Currently, jQuery-UI and jQuery are still widely used, and some JavaScript is embedded directly in ERB templates.
- Some legacy jQuery syntax remains.
- Rails itself is moving forward with the introduction of Hotwire and the deprecation of rails-ujs.
As a starting point for discussion, I have created a branch that introduces Hotwire (the first few commits have already been submitted as patches: #42517, #42521):
https://github.com/tohosaku/redmine/tree/hotwire
My experience so far can be summarized as follows¶
- Around 120 commits were made, covering the following changes:
- Removal of jQuery-UI and jQuery
- Removal of JavaScript from ERB templates
- Modularization of all JavaScript (including jstoolbar, attachment, contextmenu, etc.) using ES modules
- Introduction of Turbo
- All work was done without the use of AI coding tools
- Introducing Stimulus eliminates the need to rely on Rails’ automatically generated DOM element IDs for JavaScript event handlers, improving code clarity.
- Moving all template JavaScript into Stimulus controllers resulted in 96 controller files in total.
- SJR (js.erb + rails-ujs) and Turbo Streams are nearly identical, which makes implementation relatively straightforward.
- When implementing Turbo Drive, the
DOMContentLoaded
event is not triggered during page transitions. This requires significant rewrites of event handler logic. (Hotwire’s introductory articles often suggest simply replacing it with theturbo:load
event, but this is not always sufficient.)
- In the
importmap-rails
environment, all registered libraries are preloaded by default. This means libraries used only in specific views, such as Chart.js and gantt.js, are downloaded by all users. By settingpreload: false
and usingdynamic import
in the Stimulus controller, libraries are only loaded when the relevant screen is opened.
Issues that have emerged during development¶
- Plugin compatibility
A compatibility mode may be required for plugins that still depend on jQuery.
- Stimulus does not provide namespacing
Conflicts can occur if multiple plugins define Stimulus controllers with the same name, similar to conflicts with non-namespaced CSS selectors or non-modular JavaScript functions.
- Changes in JavaScript customization methods
ES module–based code makes direct function overrides more difficult. We need to consider how to extend them through plugins such asview_customize
.
It may also be worth confirming whether Stimulus controllers can be inherited by plugins and documenting this approach.
Actions