Define architecture for inline editing display

[brynwhyman]

An API should be used to define the UI of inline editing of a block. This would allow the developer to define what fields of a block should be edited 'inline' and what should be accessed via the [future] (...) menu item to be edited with the existing GridFeildDetailForm.

Investigate how this will be implemented.

Acceptance Criteria

• [x] The following issues have been reviewed, and relevant questions have been posted/answered:
  • [x] API to define inline editing display https://github.com/dnadesign/silverstripe-elemental/issues/266
  • [x] Add inline editing capability to the React ElementEditor https://github.com/dnadesign/silverstripe-elemental/issues/295
  • [x] RFC: New React based replacement for GridFieldDetailForm https://github.com/silverstripe/silverstripe-admin/issues/590
  • [x] More options for content block preview https://github.com/dnadesign/silverstripe-elemental/issues/269
• [x] GraphQL is used for API
• [x] Architecture for API(s) will include block fields (for editing) and top-level block tabs (for (...) menu)
• [x] Issue tasks have been written for https://github.com/dnadesign/silverstripe-elemental/issues/266
• [ ] Issue tasks have been reviewed by OSers
• [ ] Tasks have created for OSers to own
• [x] Architecture allows for existing API ACs to be achieved
• [x] Page performance is taken into consideration. See https://github.com/dnadesign/silverstripe-elemental/issues/269#issuecomment-410575872

[robbieaverill]

Related: #304

[ScopeyNZ]

I think we should aim for a react alternative to GridFieldDetailForm. Currently we will still need it for blocks that aren't inline editable (eg. userform blocks). Related issue: silverstripe/silverstripe-admin#590

[ScopeyNZ]

If we want to have the forms saved via a GraphQL mutation, there is an issue for this on GraphQL: silverstripe/silverstripe-graphql#17 . As long as we are using FormBuilderLoader and the API it provides we should be able to update this fairly painlessly (in theory). I suggest we use the existing REST implementation now - baked into FormBuilderLoader

[ScopeyNZ]

In regards to work for the OSSers - perhaps it would be best to discuss this while we estimate issues - opting to leave ones that might be suited for them? I'm not really sure how to decide on best candidate issue for them. Some existing issues on their repos like silverstripe/silverstripe-graphql#17, silverstripe/silverstripe-admin#556 and silverstripe/silverstripe-admin#590 would be nice to have - but not required.