Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand explanation of strands #26

Open
thclark opened this issue Feb 5, 2020 · 0 comments
Open

Expand explanation of strands #26

thclark opened this issue Feb 5, 2020 · 0 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@thclark
Copy link
Collaborator

thclark commented Feb 5, 2020

The following summary of what a strand needs to do (in the context of a react component implementing a strand for use in a front end web application) is lifted from an issue elsewhere.

Parse the useful aspects of this summary, which contains a logical breakdown of different way in which we can use strands, into the documentation.


To render or use strands in a web application, strands needs to have a similar set of functionalities, so the base strand component has different modes.

Note: It may be simpler to architect all of the strands as separate components entirely, rather than composing, but the philosophy is the same for all of them so we document it here.

Required modes

  • edit Allow editing of the strand itself (eg change of the schema)
  • populate Allow population of the strand with data (eg to configure a digital twin at launch)
  • show Allow the strand to be viewed for informational purposes (e.g. this is the spec of a digital twin)

Views

  • Human example view showing example configuration form (disabled, show and edit modes)
  • Human view showing actual configuration form (enabled, populate mode)
  • Machine (code) example view showing example configuration data (disabled, show and edit modes)
  • Machine view showing actual configuration data (enabled in populate mode)
  • Machine view showing the strand, eg the schema or the raw json list of children (disabled in show and populate modes, enabled in edit mode)

Async validation

In theory, async validation (e.g. of things not put in the schema, like permission controls) should be possible but is out of scope for the current demo stage, and with care shouldn't be required anyway. We should stick to the philosophy:

If data passes json schema validation it is valid. So any async validation should simply be applying the same identical check.


@thclark thclark added the documentation Improvements or additions to documentation label Feb 5, 2020
@thclark thclark self-assigned this Feb 5, 2020
@thclark thclark added this to Twined v0.1.x in Twined Ecosystem Roadmap Nov 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
Status: Priority 1 (Low)
Development

No branches or pull requests

1 participant