Either commit to React or remove it

<%- if @topic_view.topic.tags.present? %>
<%= t 'js.tagging.tags' %>: <%- @topic_view.topic.tags.each do |t| %> <%= t %> <%- end %>
<% end %>

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

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