Editors need refinement (#259) · Issues · clean-and-itasks / iTasks-SDK

Editors need refinement

The current Editor is usable but still has a set of seemingly unrelated smaller issues that appear to be caused by the its fundamental design choices (one model value, untyped additional state, an explicit record instead of overloading etc.). We need to identify these issues and refine the Editor type to address them all together. That way we can understand potential tradeoffs. Some of the problems are issues #258, #250, #207

Things that should be considered:

'Model' data vs 'Additional data': When composing editors we have only the 'value' of an editor to manipulate. In something like a dropdown we can see a clear separation between the chosen value, and the data that is needed to chose that value.
Modes. All editors currently have to support enter/update/view modes. This is an artifact from how we originally designed the generic editors. Do we always need all three modes? or can we make editors that can be used for just one purpose (or maybe two)?
Composition. It should be possible to construct editors from other editors.
Typed vs untyped editor state. To be able to compose editor states we now use an untyped structure for server-side state. Could we make this typed in the specification of editors?
State-based interface vs event handling. Currently composing editors with buttons is weird. Buttons only have to expose their click event through a change in their state. We need something like a trigger to compose stateful editors with components like buttons that only trigger a state modification.
Multiple roundtrip rendering. The SVG based image editors need a complex interaction to first do partial rendering/measuring in the browser before the full image can be computed. Can we support such interactions more easily?
Sharing of incomplete state: When editing collaboratively, you also need to share partial incomplete state between users. Currently this can't be shared because it is not part of the editor value.
Synchronization and conflicts. In the past we had version numbers and conflict resolution when data is edited concurrently. The current editors no longer have this, which could lead to inconsistent state.
Client-side behavior. Should client code be an core part of editors, or should it be optional?

The current `Editor` is usable but still has a set of seemingly unrelated smaller issues that appear to be caused by the its fundamental design choices (one model value, untyped additional state, an explicit record instead of overloading etc.). We need to identify these issues and refine the Editor type to address them all together. That way we can understand potential tradeoffs.
Some of the problems are issues #258, #250, #207

Things that should be considered:
- 'Model' data vs 'Additional data': When composing editors we have only the 'value' of an editor to manipulate. In something like a dropdown we can see a clear separation between the chosen value, and the data that is needed to chose that value.
- Modes. All editors currently have to support enter/update/view modes. This is an artifact from how we originally designed the generic editors. Do we always need all three modes? or can we make editors that can be used for just one purpose (or maybe two)?
- Composition. It should be possible to construct editors from other editors.
- Typed vs untyped editor state. To be able to compose editor states we now use an untyped structure for server-side state. Could we make this typed in the specification of editors?
- State-based interface vs event handling. Currently composing editors with buttons is weird. Buttons only have to expose their click event through a change in their state. We need something like a trigger to compose stateful editors with components like buttons that only trigger a state modification.
- Multiple roundtrip rendering. The SVG based image editors need a complex interaction to first do partial rendering/measuring in the browser before the full image can be computed. Can we support such interactions more easily?
- Sharing of incomplete state: When editing collaboratively, you also need to share partial incomplete state between users. Currently this can't be shared because it is not part of the editor value.
- Synchronization and conflicts. In the past we had version numbers and conflict resolution when data is edited concurrently. The current editors no longer have this, which could lead to inconsistent state.
- Client-side behavior. Should client code be an core part of editors, or should it be optional?

Edited Oct 25, 2018 by Bas Lijnse

To upload designs, you'll need to enable LFS. More information