search

userfrosting / UserFrosting

Modern PHP user login and management framework
https://www.userfrosting.com
Other
1.63k stars 369 forks source link

Possibility of having a reactjs or Vue.js based front end (open to suggestions) #836

Open abdullahseba opened 6 years ago

abdullahseba commented 6 years ago

I'm been thinking about having a react js based version of userfrosting. The main reason for this being performance and code quality. Both Reactjs and Vue.js allow Jquery based plugins to be used in a wrapper which we might be useful if we cant find a native alternative. Both also use web complements which would be a bit like how we use twig templates currently.

Both are also just view frameworks so to implement ajax for data handling axios seems to be the best option. https://github.com/axios/axios

Userfrosting is often used in large applications which means we should probably use redux for react or vuex for Vue.js. Redux and vuex make it simpler for components to talk to each other which gets really messy otherwise. As I understand its basically like a middleware that stores any data needed by components and detects any changes to update the dom. All ajax communications would also sit there. image Saying that if we use a multi page structure we might not need a state manger at all.

Where I would most appreciate feedback is on what structure to use, a single page , multi page or a hybrid. I think uf could ship as a single page but with hybrid support though it would require a more work to allow sprinkles to extend pages. Maybe even keep twig and have twig-js templates so that twig combines everything rather then having to do do it in the sprinkle manger. Keeping twig would also make it easier to create multi page hybrids if single page would be too large for applications like an online shop for example.

image

The structure would also affect how we use routers. A single page would use the vue or react router while a multi page would continue using a server side router. A hybrid would obviously use both. A single page structure would still require a server side router for the api's regardless.

I am no expert on react or vue by any means so any feedback or suggestions are welcome.

Vue.js has a lot of nicer features and supports pug which might be a nice solution for templating. On the other hand React has wider support and a bigger attraction from a marketing point of view. Also using react js might make it somewhat easier to create mobile app using react native.

https://hackernoon.com/code-reuse-using-higher-order-hoc-and-stateless-functional-components-in-react-and-react-native-6eeb503c665 https://medium.com/@aakashns/sharing-components-between-react-and-react-native-f6ce3713658a

Vue.js have a good comparison between its self and react. https://vuejs.org/v2/guide/comparison.html

Silic0nS0ldier commented 5 years ago

Something to had regarding usage of redux (and similar global stores). We'd need to nail the implementation. Its is trivial to implement in a way that will make future maintenance torture, as I've learnt from a handful of projects at work.

However we go about this, there will be a lot of complexities to keep in mind beyond just Redux. As I've mentioned elsewhere, our best option here may be to have a library which people may opt to use plus a boilerplate people can work from. Given the pace at which frontend tooling evolves, we will want to keep it as flexible as possible.

abdullahseba commented 5 years ago

Would it perhaps be better to not use state management by default? UF by itself is not complex enough to validate it, I don't think. But applications created with UF are likely to be so. I still have no experience in this, but is it viable for UF's frontend to be open to any state management framework of the developers choosing?

Silic0nS0ldier commented 3 years ago

We'd need to nail the implementation.

Something I have learned about Redux over the past 2 years, it is the worst possible option for state management. This isn't to say that it can't be used right (it can) however rarely do I see it not become used as a massive global store, a massive antipattern that makes projects borderline unmaintainable. Libraries like immer help, but there are better approaches.

One such better approach is mobx, which I've become quite fond (its used extensively in Canva). It is quite a lot easier to keep state localised, and with appropriate component composition patterns makes it easier to test business logic.

is it viable for UF's frontend to be open to any state management framework of the developers choosing?

Yes. Out of the box UI will naturally need something to maintain state however by no means will it lock developers in. Further, much of the UI will be defined in a cross framework manner (using web components, at least that is my plan), so the out of box code should be fairly minimal compared to what we have now.

As for the frontend, preference thus far is looking to be Vue for the project boilerplate (possibly with a plain HTML SSR option to help those on UF v4 make the version jump, which like with v3 to v4 I expect will be quite disruptive.

Relevent:

abdullahseba commented 3 years ago

I've only really used Vuex - and not extensively at that. What I will say is that Vue 3 has a new reactivity system that makes Vuex redundant for many simple tasks that would otherwise be messy to implement without a store.