Javascript Stack: our next challenges

Add bulk action support to Table component, see UX improvement - bulk delete things, maybe general bulk actions
Add usage example for a Table/Index page in React
Add usage example for an Edit/Create page in React
Update the “how to create a plugin?” documents
Come up with good tutorials about react development in plugins
Add async import support to the vendor project
Move the assets pipeline stack to webpack (css and js)
Replace UI ruby gems with React implementations, see Legacy JS - things we might want to remove/replace at some point
The ToastNotifications uses wrong practices, need to redesign and stop using jquery there
Move organizations handling from katello to foreman
Deprecate or update jquery
Switch from npm to yarn
Replace the loading indicators with an approach similar to react-loadable
Introduce client support for `websockets’

Want to contribute?

If you would like to contribute to the effort or just want to work on UI/JS feel free to reach out and we can set it up together.

Also, feel free to disagree or add your suggestions, any feedback would be appreciated.

Thanks!

jeremylenz · November 25, 2019, 2:46pm

Some things that come to mind for me:

Replace redux-thunk with our own Redux middleware, and get rid of all our overly complex action creators. Our own middleware could track API request actions and dispatch success/failure actions as needed; “magic” third-party software is not required. This infrastructure is almost complete already (thanks @Ron_Lavi), but I also think it’s worth refactoring our existing action creators once best practices are established. I think thunks make our code too difficult to understand, especially for someone just “dabbling” in React/Redux and not an expert.
Upgrade to Patternfly 4 (yeah, I know. But you can still dream.)
Find a way to use a composable React table component like this one instead of the Patternfly approach of assembling complex objects first (this may or may not involve Patternfly upgrade)
Have less of a tolerance for bad usability and performance in general. I think small issues like these are worth raising, and while not significant on an individual level, on the whole they can make a huge difference in the quality of our UI and thus the happiness of users.

jeremylenz · November 25, 2019, 3:20pm

Replace the loading indicators with an approach similar to react-loadable

@sharvit this looks cool! Also makes me think about React suspense for data fetching, which solves the same problem but isn’t quite ready yet. The API looks similar though, so it would be easy to switch.

jeremylenz · November 25, 2019, 3:27pm

This also makes me think about our current approach to React components, and how we mostly use React just for parts of a page using mount_react_component. I think we would get so much more benefit if we convert an entire page at a time to React, instead of adding more ReactDOM.render mount points. You get the full benefits of React Router, a much faster page, and easier integration with the rest of the React app. If we start converting some of our old pages to React, it would help a lot with the technical debt around jQuery (and Angular).

ekohl · November 25, 2019, 3:29pm

Thanks for this. Greatly appreciated.

Will it be done in time for Foreman 2.0?

sharvit · November 26, 2019, 10:22am

Notice the “middle of January” thing is about the current roadmap, without the “Whats next?” section.

ekohl · November 26, 2019, 2:37pm

I get that but I was wondering if we can say with Foreman 2.0 the use of Webpack/React is officially supported and recommended for plugin developers.

sharvit · November 26, 2019, 3:05pm

Yes