RFC: Using React

[dandlezzz]

The problem

The solidus admin frontend does not use a modern JS framework in its implementation. This is problematic for several reasons. 


1. Aspiring frontend contributors can not rely on their accumulated knowledge of something like React or Vue to make contributions.

2. Our frontend dependencies are quickly falling out of fashion. This makes it more difficult to leverage the rest of the current JS ecosystem.

3. Most importantly, modern JS frameworks increase productivity allowing for more rapid development of the Solidus admin frontend.

Proposal

Assuming we resolve https://github.com/solidusio/solidus/issues/3077, relatively soon. We should move to adopt React as the Solidus Javascript framework. The transition to a frontend fully powered by React will take considerable effort. But we can do it one component at a time. React can play nicely with other javascript frameworks and dependencies. By taking an incremental approach, we can avoid the need for a massive rebuild. Additionally, by opening up issues for contributors to rewrite existing frontend components, it should help us attract a whole new crop of frontend developers, attracted to the prospect of small straightforward tasks.

[ericsaupe]

I think the long term goal of the Solidus frontend is to separate it out into various projects of various flavors, HTML, React, Vue, etc. I agree a new frontend is definitely needed but a new solidus_frontend_react gem could be started today.

[kennyadsl]

Hey @dandlezzz, thanks for your input. The problems with using React for our Admin frontend, as reported in #3077, are:

1. there's no way to distribute a JavaScript package via a RubyGems. This means that we should create one or more external npm packages along with the Solidus gem and users will need to take care of keeping them in sync, which is far from ideal.
2. It's not super clear how we could use extensions and host application code to eventually change what would be shipped in core. I mean, what if I want to change how a component provided by Solidus behaves on my store using Webpack and React? Now we have this procedure, what should be alternative?

[dandlezzz]

@kennyadsl Those are some valuable points. What about if we leverage something like, https://github.com/reactjs/react-rails. This would allow us to distribute react components and use them in views without having to maintain a seperate npm package. Additionally, this should provide some nice override functionality. Granted, you won't be able to customize individual components but you will be able to use all of the components bundled by the rails app to compose a view.

[dhonig]

So I think it would be fine to use something like react-rails through webpacker. I'm using this approach now for an 18 month old project and it works well. What's wrong with a ruby gem that wraps an NPM module? Its an odd duck. But fundamentally I see nothing wrong with doing this.

I think the best approach to the admin backend is to create a GraphQL Admin API and then create a Gatsby/Next.js Admin interface on a MobX/Apollo Client and one of (React/Vue.js) This would deliver a modern experience and ease customization. I will constanty argue that there we should move towards a GraphQL centric approach to front and back end. Indeed its alot of work, but we are getting there.....Its also a major break from the current generation of Solidus. So it brings up deeper issues of what Solidus is now and what it should become.

On Wed, Jul 3, 2019 at 12:49 PM Daniel notifications@github.com wrote:

@kennyadsl https://github.com/kennyadsl Those are some valuable points. What about if we leverage something like, https://github.com/reactjs/react-rails. This would allow us to distribute react components and use them in views without having to maintain a seperate npm package. Additionally, this should provide some nice override functionality. Granted, you won't be able to customize individual components but you will be able to use all of the components bundled by the rails app to compose a view.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/solidusio/solidus/issues/3246?email_source=notifications&email_token=AABZTLYVYJMUDQQ3RDLI3JDP5TKADA5CNFSM4H5ABF22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZFBKOA#issuecomment-508171576, or mute the thread https://github.com/notifications/unsubscribe-auth/AABZTL2SVA36L4UKQUVECWDP5TKADANCNFSM4H5ABF2Q .

[octoxan]

In my opinion we should use Vue and not React as its much more beginner friendly, less bloated, and has just as big of a community now. It's also not a Facebook product.

[dhonig]

Xan, Solidus should really be API centric and framework agnostic. Different companies/partners can offer starter kits in frameworks they specialize in. GraphQL should be the primary api.

-dh

On Fri, Aug 9, 2019 at 11:02 AM Xan Bertison notifications@github.com wrote:

In my opinion we should use Vue and not React as its much more beginner friendly, less bloated, and has just as big of a community now. It's also not a Facebook product.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/solidusio/solidus/issues/3246?email_source=notifications&email_token=AABZTLYZTICPQZYM4QNM223QDWBG5A5CNFSM4H5ABF22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD365VFQ#issuecomment-519953046, or mute the thread https://github.com/notifications/unsubscribe-auth/AABZTLZTQUNDQSPSJ2FRINLQDWBG5ANCNFSM4H5ABF2Q .

[octoxan]

@dhonig 100% agreed. Framework agnostic and GraphQL API centric is ideal. My comment was just that if Solidus were to adopt a framework, it should not be react.

[tvdeyen]

if Solidus were to adopt a framework, it should not be react.

💯 ack

[jacobherrington]

Framework agnostic should be the goal. I like React, but I wouldn't want to push that opinion on everyone who wants to use a frontend framework with Solidus.

[jacobherrington]

We talked about this in the core team meeting today; we want to be strongly framework-agnostic when it comes to store frontend user interfaces. We would love to have more contributors to the GraphQL API that is being built for Solidus: https://github.com/solidusio-contrib/solidus_graphql_api That will allow people to create anything they want with modern JS frameworks.

When it comes to the admin interface, we are not going to be strongly opinionated. However, it's important to remember that Solidus is a Rails Engine, so we must exist within those limits.

[rsmithlal]

Cool! Have you ever published any design documents for the front end modelling? It would be nice to have a set of consistent design docs that could be used to build front ends in various frameworks.

[waltjones]

Are people still actively working on this, and is there updated status? I noticed it is listed as 'in progress' on the public roadmap. https://solidus.io/roadmap/

Thanks for any update.

[kennyadsl]

This issue was meant to replace the current admin frontend with React. As of today, no change has been made in this direction. Personally, I also think this won't happen because of the nature of the admin panel, distributed as a gem. It's more likely that we introduce some other technologies, more standard in the Rails ecosystem, like ActionView::Component and Hotwire (there's a spike here).

The roadmap task is more about providing a starter frontend that uses React as opposite to the default frontend that Solidus currently provides.

[waltjones]

Makes sense, and thanks for the response.