RFC: Adding ReactJS to SilverStripe CMS

556 views
Skip to first unread message

David Craig

unread,
Oct 15, 2015, 10:55:38 PM10/15/15
to SilverStripe Core Development
Hello,
We've been having lots of fun with ReactJS recently. What do you think about this https://github.com/silverstripe/silverstripe-cms/issues/1301 ?

David

Shea Dawson

unread,
Oct 16, 2015, 5:47:32 PM10/16/15
to SilverStripe Core Development
I think this is really exciting. Many of the content administration operations done in the CMS feel unnecessarily heavy and sluggish when compared to the new standard being set by modern web apps. As a result I never look forward to doing any large amount of content admin work in the CMS (or passing it on to someone else).

I've been wanting to learn a js framework like react for a while now and this sounds like a great opportunity to learn while helping to improve CMS user experience at the same time. Also great to hear that it can be gradually introduced component by component, and will give some structure to the way we develop modules... and all of the other benefits you pointed out. Awesome stuff.

Looking forward to checking out what you've done already and learning from that :)

Thanks!

Uncle Cheese

unread,
Oct 18, 2015, 6:02:13 PM10/18/15
to SilverStripe Core Development
A CMS using more React components is a wonderful idea, but I think we need to be a bit cautious of creating a wild west of plugins without any structure or design pattern imposed on them. React is not a framework, it's just a library, so I think it's to SilverStripe's benefit to provide a framework for how to build React components that integrate with the CMS backend.

One idea would be to have our own opinionated Flux framework that worked specifically with the CMS, so that actions could be called that connected to your LeftAndMain endpoints. For example, subclassing a ReactFormField component would get you all of the /EditForm/field/FieldName endpoints for free.

There are a lot of different ways we could go with it. Unlike Angular, Ember, et al, React really needs structure, otherwise it can become very obtuse.



On Friday, 16 October 2015 15:55:38 UTC+13, David Craig wrote:

David Craig

unread,
Oct 19, 2015, 3:28:34 AM10/19/15
to SilverStripe Core Development
I agree - but I think that's a conversation we need to have if this RCF gets accepted. I'd like to keep this focused on React being a good idea or not :)

Will Morgan

unread,
Oct 23, 2015, 1:24:04 PM10/23/15
to SilverStripe Core Development
I'm all for using a "standard" JS framework for the UI much in the same way we're swapping out old components for "standard" components for the backend.

+1 from me.

David Craig

unread,
Oct 26, 2015, 6:00:16 PM10/26/15
to SilverStripe Core Development
Thanks everyone for taking the time to review this. The feedback has been pretty positive at this stage. Just to recap...

- We're proposing ReactJS is added to core.
- Some of the benefits include: Faster user experience, maintainable and modular code, testable front-end, composable UI components.
- There will be discussion on adding ReactJS to core at the next core committers hangout.
- There is further discussion required around the architectural approach we take (do we use Flux for example), the tool chain, and how we handle ReactJS upgrades. 

I'm going to investigate the this stuff over the coming weeks, how it will fit with current RFCs (https://github.com/silverstripe/silverstripe-framework/issues/4372 and https://github.com/silverstripe/silverstripe-framework/issues/4606), and how it might impact existing tooling (Behat testing for example). I'll post updates here so stay tuned :D

On Friday, 16 October 2015 15:55:38 UTC+13, David Craig wrote:

Sam Minnée

unread,
Oct 26, 2015, 7:00:55 PM10/26/15
to SilverStripe Core Development
Hi David,

I think that it would be good to think about "how will JavaScript look in SS4?" as a whole, incorporating the dependency management, asset pipeline, and ReactJS thinking, as well as recognising that there will be a lot of Entwine code in core & modules for SS4, and understanding how that will fit nicely with the rest of things.

Thanks,
Sam

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

Wilfred Godfrey

unread,
Oct 27, 2015, 4:53:08 PM10/27/15
to SilverStripe Core Development
You have my support. React seems to be a better standard UI framework than most.

Fred Condo

unread,
Oct 28, 2015, 12:37:13 PM10/28/15
to SilverStripe Core Development
I quite agree with Sam, and will venture to say it's too soon in the process to choose a particular library. Why not Ractive.js, for example, with its bidirectional binding and in-built mustache templating? If, after we properly address "how will JS look in SS4?", ReactJS is the best fit, I'll be all in. But not today.

Ingo Schommer

unread,
Oct 28, 2015, 3:47:50 PM10/28/15
to silverst...@googlegroups.com
I'm really excited by the prospect of a reactive, data-driven UI in SilverStripe!

My exposure to ReactJS has been fairly limited. I was initially worried about the added complexity of debugging a virtual DOM layer, but after talking to a few devs with ReactJS experience that seems to be a non-issue - it just works.

@Fred: While I agree that we need an overall plan for JavaScript in JS, I think we need to start somewhere - it's a huge topic, and new approaches pop up every day. The question should rather be: Do we have enough modern JavaScript knowledge in the core team and community to lead us on a stable architecture path? As Aaron pointed out, choosing ReactJS as a frontend library means we need to make more decisions (e.g. Flux, testing, modularisation) than if we're using a broader, more opinionated framework like AngularJS. And I'm confident we have that potential to make these decisions.

Responding on Klemen here, rather than fragmenting the thread
 
Hi guys, ReactJS sounds like an awesome choice and you have my +1. Out of curiosity - Angular is not a contender?
Do I understand correctly that essentially for SS4 CMS you are decoupling logic/API and the CMS views? Or would integrating React actually mean a heavy rework of what's out there (note I'm not too familiar with state of progress, but felt this was a conversation I wanted to join in). Doing that kind of decoupling, that would mean that integrating angular or another front-end framework could come out of the box.

In order to integrate efficiently with React or Angular, we'll need to expose data structures like page content, the page tree and a form schema through an API. So yeah, that's the plan. We're not sure yet if it's going to be a general purpose REST API, since there's a lot of complexity around expressing the different data states and query possibilities. You'll be able to use it in other frontend frameworks, it's just a matter of treating it as a CMS-internal feature or a public "SilverStripe API".
 
If intelligently done, SS could integrate pretty rapidly with frameworks like Polymer or Ionic (on the frontend as well). And maybe even be "themable" in a way that up to now was largely impossible (e.g. Polymer, Bootstrap, Material, Foundation themes for backend being relatively a breeze)
We have recently done multiple sites on Ruby/Angular and I keep missing SS's modular approach to building view elements. Essentially we need to build out all the interfaces by hand and I always dream of an angular version of "new Form()".
To finish this off, I think my mentioning of Angular essentially serves as a +1 for ReactJS. If we could somehow bridge the gap and have whatever JS "MVC" framework is the basis for the CMS to receive schema(mode) / form information from the "SS API", then this would open up very exciting possibilities (and possibly a reactive, non-refreshing CMS interface).
Has anyone seen and worked with Meteor? That thing is reactive out of the box.

I've worked with Meteor recently, and am fascinated by its isomorphic approach. It's very much an opinionated full-stack framework though (e.g. MongoDB and Node only). My experience so far is that it's incredibly quick to get a reactive UI and data store going without even knowing what Websockets are, but you pay for this later by a steep learning curve. For example, I've given up trying to run Selenium tests on my Meteor app, there's just too much magic going on. Getting a bit off topic though ;)




 
--
Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

Conrad Dobbs

unread,
Oct 28, 2015, 4:46:50 PM10/28/15
to SilverStripe Core Development
Not long ago I worked on a site which was originally built in Backbone then had SilverStripe tacked on later. It was a mess, a lot of the features of the CMS just couldn't be used with the way it was implemented.

I ended up rebuilding the frontend so it could integrate better, the main driver being multilingual support.

The point being, using something like ReactJS would be awesome, but there will be quite a few challanges with moving templates into the frontend as they won't integrate as tightly with the CMS.

Ingo Schommer

unread,
Oct 28, 2015, 5:30:23 PM10/28/15
to silverst...@googlegroups.com
Just to clarify: We're not prescribing how you build your own sites with this. It'll likely be a bit easier to build single page apps because we'll naturally have more focus on SilverStripe's REST API capabilities. But you can also continue generating SSViewer-based templates in PHP as usual. The discussion here is about using ReactJS as the primary UI library for the majority of CMS UI components. And even there, things will be composable - you'll be able to use e.g. a jQuery Plugin for a tag autocomplete field that's rendered within a React-powered CMS form.

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Oct 28, 2015, 10:03:03 PM10/28/15
to silverstripe-dev
Some more cents worth below ... 

On 27 October 2015 at 12:00, Sam Minnée <s...@silverstripe.com> wrote:
Hi David,

I think that it would be good to think about "how will JavaScript look in SS4?" as a whole, incorporating the dependency management, asset pipeline, and ReactJS thinking, as well as recognising that there will be a lot of Entwine code in core & modules for SS4, and understanding how that will fit nicely with the rest of things.


​+1 - I think we really need to look the JS as a whole, on a more fundamental level.  I think once we define the framework for this then it is easier to make decisions like "ReactJS: to add or not to add​?" as we know why we are doing it and we can asses the pros and cons based on our overall goals. 

Alternatively, t
he way I could see it work is that Framework is simply basic PHP without any JS and that the CMS is highly opinionated piece of software in the hope that some people would find it so offensive that they build an alternative CMS module
​. ​

 Do we have enough modern JavaScript knowledge in the core team and community to lead us on a stable architecture path?

​Why not add someone to the core team with this knowledge - if this is what is required to be the world's best? 

Nicolaas


David Craig

unread,
Oct 29, 2015, 4:25:08 PM10/29/15
to SilverStripe Core Development, n...@sunnysideup.co.nz
That's something I've been thinking about and discussing with the team. I'm currently working on an approach for SilverStripe React components to communicate with legacy modules. React should be an addition rather than a replacement to Entwine modules initially. They seem to play pretty well together. See https://github.com/open-sausages/silverstripe-reactjs-common/pull/4

Conrad Dobbs

unread,
Oct 29, 2015, 4:46:49 PM10/29/15
to SilverStripe Core Development
CMS was probably a poor choice of words, framework would be better. How things like i18n are integrated.

It would be awesome if the development brings about some good APIs which can be used for website builds as well. Previously, when building ajax based sites I'd looked at the way the CMS did it but was put off by some of the code comments saying the API will likely change in the future. If the separate components required can be developed into stable standalone components then there will be a lot more benefits. 

David Craig

unread,
Oct 29, 2015, 10:42:36 PM10/29/15
to SilverStripe Core Development
i18n is handled like this https://github.com/open-sausages/silverstripe-assets-gallery/blob/master/public/src/component/gallery-component.js#L67

The i18n module is just a wrapper around the current window.ss.i18n global.

Conrad Dobbs

unread,
Nov 2, 2015, 4:38:14 PM11/2/15
to SilverStripe Core Development
So is the short term goal to create new components with ReactJS while leave existing code in entwine? With long term strategy moving all components to ReactJS?

One concern would be ending up with a mish mash of libraries like 2.4, but it might be necessary while transitioning.

Like Sam, I think it would be good to have an idea of the end goal, what libraries, frameworks, build tools etc would be used on the frontend in an ideal world for SS4 and going forward.

David Craig

unread,
Nov 2, 2015, 5:05:26 PM11/2/15
to SilverStripe Core Development
Yeah that's right, the first step is build new components in React, while making sure they work with existing Entwine components. Then over time upgrade the various Entwine components to React. I've written some docs on how we can interface React and Entwine components here.

In terms of build tooling and libraries, there's a couple of existing RFCs, one has been accepted. RFC-4 (accepted) covers dependency management with npm and a lightweight Gulp build. There's also RFC-7 which covers module management with ES6 / Browserify. React fits well with both of those RFCs. Something that isn't explicitly mentioned is unit testing, however we have React unit testing set up using Jest, which is built into the npm / Gulp toolchain.

David Craig

unread,
Jan 19, 2016, 8:00:10 PM1/19/16
to SilverStripe Core Development
Hi everyone,
You might have seen a few RFCs coming out recently around the proposed implementation of ReactJS in SilverStripe 4. I though it would be a good idea to consolidate some of those ideas here.

ReactJS in SIlverStripe

We propose using ReactJS to power the UI of SilverStripe 4. It will allow a more powerful CMS UI based on more well defined data flows and UI components, leading to a more consistent structure on the long term. SilverStripe 4 will mark a transition phase in this effort. Our initial focus is on the asset section - we’ll need your help to convert all existing jQuery.entwine and PJAX behaviour!


State management

Given the UI of the SilverStripe CMS is written using ReactJS, there needs to be a pattern for managing state, which is consistent and extendible. The state management pattern we’re proposing is Redux, which has some great advantages due to its single store approach, and being written in functional programming style.

GitHub issue - RFC: UI State management

UI Extensibility

A major goal of the new CMS frontend implementation will be decoupling client-side components from backend components. Most components will be rendered via frontend logic (ReactJS components), and consume structured data from the backend (rather than raw HTML generated in SilverStripe templates). We propose using the bottlejs dependency injection library to make the core application UI extendible.

GitHub issue - RFC: UI Extensibility

React forms

When implementing React based frontend components, there is limited ability for forms declared via PHP to influence the front end. Likewise, the development of custom components used in frontend ReactJS based forms would require re-implementation of that behaviour via the traditional SilverStripe Forms API.

We propose that we create an intermediary data schema (form field schema), in order to map an abstract representation of the form backend, to the frontend rendering mechanism (ReactJS).


We'll be posting more info on application structure and configuration soon, so stay tuned :) 


Reply all
Reply to author
Forward
0 new messages