Either commit to React or remove it

Feature Ideas
1

A common requirement when creating a module to introduce new features into Silverstripe is to create a new form field/component

With the current process there is no solid documentation on how to achieve this. There is a one page guide which outlines some ways in which you can modify existing components but not create new ones

So what context does a developer need for creating a module that works on both the CMS level for pages and on the react level:

  • Knowledge of Entwine
    • First, context of what entwine is (where would they get this context?)
    • Second, knowledge of how to wire a react component up in entwine
      • For this they would be required to have context of existing modules
  • A basic understanding of React
    • This is a reasonable requirement
  • Knowledge of how state is managed within redux, how the initial state is passed through to the field, what role schemaComponent, getSchemaStateDefaults, getSchemaDataDefaults play in setting the state of the React component
  • An understanding of how to bundle up their JS
  • Knowledge of the silverstripe-module
    • And that if they want to develop with the admin/external JS files they need to run composer install --prefer-source
    • And if they want to modify the webpack config how that has been set up
  • How to add the requirement for the JS file when the field loads
  • Where the templated .ss file should live for admin fields
    • How that field should look for a react field that’s loaded in through entwine
  • If the field contacts the server than the expectation would be to use the admin graphql endpoint, so they need to know:
    • How to interact with GraphQL
    • Use a specific version of Apollo that’s loaded through the admin module
    • How to register queries with the injector

They need to achieve all of this with very light documentation. You may be reading it and thinking, oh this person has gotten X wrong in the list of required knowledge. That’s a fair statement, I probably have. But that’s the key point I’m getting at.

This is too complex

We’ve reached a point where we expect anyone that wants to contribute features and functionality to have too much context. They need to know both the old and the new. They need to know both of these without terse, easy to understand documentation.

Either Silverstripe needs to commit to React or remove it.

When I say commit I mean:

  • Create thorough documentation
  • Remove entwine
  • Create example modules executing the basics well for others to be able to look at and understand
  • Reduce the complexity required to make meaningful contributions

This middle state of having both and a high level of complexity is not going to increase the likelihood of someone contributing to the ecosystem but remove it. It’s going to make it harder for people to justify those contributions

2

I’ve found this difficult in the past and I’ve written a blog post about creating a field here: Creating a new field in Silverstripe | Blog

Hopefully it helps you or anyone else that’s looking for help with creating fields in the future

2 Likes
3

If I had a say in this, I’d vote REMOVE
(As a Dutch saying goes, it’s better to stop half way than to persevere in an error – not sure if it still makes sense translated)

I’d be interested in an assessment of the amount of time/work actually spent on converting stuff to react over the past years (including the all the GraphQL stuff) by Silverstripe devs. I doubt it still warrants the anticipated benefits (not sure what these actually are/were other than just replacing Entwine).

There’s also some (maybe unforeseen) cost to the react vendor-lock-in, as I suspect it to at least being partly the reason some of the most widely used community modules have not been updated and the framework has lost a lot of its KISS & DRY principles, just to name a few on top of mind;

  • UploadField sadly does not work in a non-react front-end
  • Betterbuttons, especially Save and Close & Nested Form

We ourselves are not using react in our own front-ends simply because we’ve never actually had a project where the amount of work involved in creating stuff in react seemed to be reasonable for the purpose. Interestingly, the link by @adrhumphreys perfectly illustrates the amount of work involved in creating (what should be a quite simple) custom form field and would previously actually have been possible with maybe 20 lines of code.

Coincidentally I just started a rant of my own about the complexity, leaving a link here for reference: Epic: Modernise CMS UI Technologies · Issue #6689 · silverstripe/silverstripe-framework · GitHub

1 Like