Epic: React GridField

[tractorcow]

Placeholder for the list of stories to be written for GridField in react.

GridField core

• Form-schema support for GridField components Discussion: Extensibility for React GridField (future development) #386
• Minimal GridField HOC
• Minimal GridField scaffolded in react / formschema
• GraphQL backed data source for GridField
• GridField detail / edit form for react admin
• GridField gnostic react admin breadcrumbs
• Read-only gridfield [GRIDFIELD] GridField needs a useful readonly view (currently just showing "none") silverstripe-framework#3357

GridField components:

• GridField delete component
• GridField publish component
• GridField search component
• GridField pagination component
• GridField order component (may be a part of core gridfield and not component maybe?)

Note: You'll need the zenhub.com browser extension to see the storycards in this epic

Related

• RFC: New React based replacement for GridFieldDetailForm
• RFC: React/GraphQL GridField
• Passing data into a React GridField
• Extensibility for React Gridfield

[chillu]

Just getting my head around what customisation a GridField would need to support. I think there's two types: Built-in customisations, and third-party customisations. I suspect we can get a lot of mileage by just making the built-ins work well, but we need to at least have an architecture for the level of flexibility required for third-party customisations.

Use cases:

• Cell casting (e.g. dates, currencies)
• Cell formatting (e.g. breadcrumbs, truncation, thumbnails, strikethrough for deleted records)
• Add columns (e.g. checkboxes for batch select, select additional columns)
• Row presentation (e.g. view as thumbnail grid, grouping, summary rows)
• Row and cell behaviour (e.g. inline form fields, expandable inline edit form, drag-to-reorder, conditional selection of items)
• Row action behaviour (e.g. confirmation dialog on actions, conditional detail edit form links)
• New actions above/below table (e.g. export button, batch action dropdown, custom "add new" selector)
• Header/footer presentation (e.g. add subtitle, change pagination summary)
• Modify GraphQL query (e.g. inline search, change sort order, pagination)
• Modify data loading behaviour (e.g. replace pagination with infinite scrolling)
• Modify layout (e.g. move pagination bar to top)

Some notable existing third party customisations:

• https://github.com/symbiote/silverstripe-gridfieldextensions
• http://addons.silverstripe.org/add-ons/micschk/silverstripe-groupable-gridfield
• https://github.com/webbuilders-group/silverstripe-gridfield-calendar-view
• https://github.com/axllent/silverstripe-tiled-gridfield
• https://github.com/webbuilders-group/silverstripe-gridfielditemtype
• https://github.com/danbroooks/gridfield-selectexisting
• https://github.com/marijnkampf/GridField-Icon-Row-Class
• https://github.com/samthejarvis/gridfield-summary-row

[chillu]

A few design goals from my perspective:

• GridField relies on GraphQL for data. This means every DataObject managed through the CMS needs to be exposed via GraphQL.
• Simpler data transformation should default to injected JavaScript logic (e.g. showing linked breadcrumbs in a cell)
• Complex data transformation should use GraphQL resolvers (e.g. count number of published child pages)
• GridField PHP code produces a declarative form schema, and defers any data handling to JavaScript.
• GridField presentation can be customised through declarative components
• Writing custom GridField components requires JavaScript compilation
• Most GridField customisations (e.g. field casting) do not require JavaScript compilation
• GridField data handling can be customised through injected GraphQL query modifications and injected Redux state modifications

Assumptions:

• It is not feasible for a React GridField PHP API to be fully backwards compatible with the current GridField, but we'll try to keep upgrade pains minimal
• GraphQL endpoints are fast enough to improve the overall CMS UX, even when managing 50+ types (see Cache GraphQL Schema issue)
• A React GridField will completely replace the current PHP GridField, there is no "compatibility mode" once we switch to fully React-powered forms

Current data handling requirements in GridField (by using the SilverStripe ORM):

• Filter by DataObject fields
• Manage relationship (has_many, many_many)
• Select fields on joined tables
• View fields from custom DataObject getters
• Aggregate fields on joined tables
• Filter by fields on joined tables
• Filter by callback
• Compose filters as nested conditionals
• View custom SS_List collection of DataObject
• View custom SS_List collection of ViewableData
• Enforce permissions

I think solving the DataList vs. GraphQL vs. GridField architecture is actually more important than how we represent components in the form schema, and what APIs we provide to build and customise these (lots of this has already been solved by the likes of Griddle).

[chillu]

Damian has started a PoC: https://github.com/tractorcow/react-gridfield

[madmatt]

Has there been work done looking at existing React data table implementations? There seems to be quite a few out there already, some with tons of functionality...

They might be challenging to implement in the CMS though...

[sunnysideup]

Please make sure to also make it look good so that people will actually feel great about using it.

[patricknelson]

Documenting here, for search purposes (for those without Zenhub extension*), that this also impacts SilverStripe's use of entwine, which is on the roadmap for removal per #411 (comment). If another ticket is ever created on Github to track the removal of entwine at all, I'd love to know (please note that in this thread)!

* Note: I didn't install the extension considering the privacy concerns, so I'm not sure what details are contained therein.

[ScopeyNZ]

Just want to note also that although entwine is set for removal, you are still welcome to create modules that include and use entwine. Using entwine on the CMS interface after its removal will be very hacky though - the interface should be entirely React driven.

Also, the timeframe is very long on this removal 😅

[maxime-rainville]

Yeah. That's not happening anytime soon.