Add state management and API tools to UI Library

[NateWr]

Describe the problem you would like to solve The UI Library has grown since it was adopted in OJS 3.1.x. At first, each component was a standalone app that managed its own state (like the SubmissionListPanel. However, since 3.3.x the application uses a root Page component for every page of the editorial backend. This root component manages state for that page.

This works well enough for most cases. However, we are beginning to find that different components use and interact with common pieces of data across different pages. For example, the DOI management page, the Contributors list panel, the Workflow page and the Submissions list panel all use an interact with the /submissions API endpoint and manage data about one or several submissions. Because of this, there is some duplication in the code when fetching, storing and modifying this information.

Describe the solution you'd like We should implement a tool to interact with the API and common state management techniques to get, edit and update data for common entities like submissions. This state management would provide an easy, well-documented way to get data from the API and save data through the API. And this would be available for use in any component without managing the complex parent-child relationships required in Page components.

Who is asking for this feature? As the maintainer of the UI Library, I feel this is important to ensure the library can be more easily learned and used by all members of the team.

Additional information The Vuex library is a common tool for state management with Vue.js. Pinia is a new recommended library (see discussion below).

The axios library is a popular way to interact with REST APIs, similar to jQuery's $.ajax() function but built around a Promise-based API. It is very similar to Promises in ES6, but includes support for older browsers.

[jonasraoni]

Looks like some tools have been replaced: https://twitter.com/VueDose/status/1463169464451706897

I'm using Vuex and axios in another project (which needs to support IE 11), but as soon as its support gets dropped, I'll switch to the newer things and probably give a try to Nuxt and a ready design system.

There's also faster building tools out there (vite/esbuild, swc, ...), and in our case, where we're normally working with many branches, it might be interesting to use another package manager such as pnpm/yarn pnp, which are able to share the packages and get rid of the node_modules folder.

[NateWr]

Thanks @jonasraoni! So it looks like Pinia is being recommended over Vuex for state management, and it is compatible with Vue 2.

We're still using 2 and I'm on the fence about whether or not to switch to 3. Vue 3's new Composition API is great for teams of JavaScript specialists. It makes Vue more like React and provides a better way to manage large, complex components. But it abandons the simple, intuitive approach of Vue 2 that made it so accessible to developers with less JavaScript experience. One of our goals with the UI refactor is to enable more members of the team to contribute to the frontend, so I'm nervous about the impact a switch to Vue 3 would have. But I haven't made a decision yet.

In terms of build tools, I think before we jump to a new build tool I'd want us to hire (or train up) someone with a speciality in this area. It's a complex problem with its own domain knowledge, and I'm not well suited to it. One of the big things we'll need to do in the next few years is figure out how to split our built files into smaller chunks, and reduce our overall build size by making more use of server-rendered templates (ie - moving templates for more high-level components like the SubmissionListPanel into Smarty where they can be customized by plugins and aren't bundled into the JS file).

All of these strike me as more important than the build tool, but if a better build tool (or Vue 3) helps us make this transition than I'm all for it.

[NateWr]

There's a very good response here from Evan You (Vue.js lead developer) to questions about the Vue 2 -> 3 transition and recommendations:

https://www.reddit.com/r/vuejs/comments/r1vluc/new_default_recommendations/hm3wgbj/?utm_source=reddit&utm_medium=web2x&context=3

At the moment, Vue 3 only has 15% adoption and the ecosystem is still maturing. But it looks like many of the new tools (like Pinia) are developed with Vue 2 support in mind.

[jardakotesovec]

We introduced some composables to make it easier to interact with the api (useFetch, useFetchPaginated, useUrl) in 3.5. Rather than creating additional layer for interacting with API - I would suggest to keep improving the API and API docs, so its friendly to interact with and we don't have to maintain additional layer to be in sync with it.

And we starting taking advantage of the pinia store, but thats more to make easier to expose state and methods to the components on page (including plugins). More details covered in storybook.