Project

General

Profile

Actions

Feature #43165

open

A Roadmap for the Future of Redmine View Development

Added by Takashi Kato 5 days ago. Updated 4 days ago.

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 the turbo: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 setting preload: false and using dynamic 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 as view_customize.
    It may also be worth confirming whether Stimulus controllers can be inherited by plugins and documenting this approach.
Actions

Also available in: Atom PDF