Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
abdullahseba opened this issue Jan 1, 2018 · 4 comments
Labels
architecture Related to the framework architecture frontend The frontend interface long-range planning Long term roadmap
Milestone

Comments

@abdullahseba
Copy link
Contributor

abdullahseba commented Jan 1, 2018

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

@alexweissman alexweissman added architecture Related to the framework architecture frontend The frontend interface long-range planning Long term roadmap labels Jan 1, 2018
@lcharette lcharette added this to the 5.0 milestone Apr 19, 2019
@Silic0nS0ldier
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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.

@lcharette lcharette modified the milestones: 5.0.0, 5.1.0, 6.0.0 Nov 25, 2023
@lcharette lcharette moved this from Todo 6.0 to Not Started in UserFrosting Task Planner Apr 13, 2024
@lcharette lcharette moved this from Not Started to References in UserFrosting Task Planner Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Related to the framework architecture frontend The frontend interface long-range planning Long term roadmap
Projects
Status: References
Development

No branches or pull requests

4 participants