status-im / pluto Goto Github PK

Extensions might require static data reused across components. Furthermore those data might act as default but could be exposed and made modifiable by end users (via some panel in the extensions screen)

References point to extensions elements. Make sure the syntax is unambiguous regarding:

• local vars usage (as introduced by let blocks)
• current extensions elements
• current platform elements
• elements defined in remote extensions

Custom events/actions are isolated in JS sandbox and communicate via message passing with host

Allow views to access properties passed onto them (via composition or hooks) through the @properties symbol available in let blocks.

Permissions are associated to queries and events and hooks and defined host side.

Permissions are collected, aggregated and available as part of parse result map (similar to how errors are accumulated).

Provides access to host capacities (query, events, hooks, ..)
Enforce meta element definition.

Similar to Status fiddle but for pluto.
Could be directly integrated in the documentation website, as an extra page.

Some resources:

• https://blog.expo.io/building-a-code-editor-with-monaco-f84b3a06deaf

Changes made to a playground are update live in a target host.

Potential scenario:

• initiate a session, a QR code is generated encapsulated connection details to playground (websockets?)
• host connects to the playground
• each change is pushed to host

Reintroduce a registry protocol (see here) that will encapsulate current re-frame based one.

It could live in the pluto.re-frame.registry namespace.

Context :host element should provide a :default-hook (with default implementation based on re-frame) that will be used for any hooks ne specifically providing a custom :hook.

Specifically:

• https://docs.google.com/document/d/1ixyYDKKz_cMJd3TaeBLXLGKiUJRkGlq1AWTkm2dYYfk/edit
• https://docs.google.com/document/d/1-8Wctqqsh1OSaDu6BKfwBGc5rhJFsGdwYUpHtGLbzhg/edit

Make sure all symbols used in views or references are defined.

Use re-frame registrar to improve re-frame related validation.

A host can define what query/events can be reused by a host via capacities.
Each query/events has some associated permissions requirements that will be aggregated and made available to host at parse time (similar to how errors are handled).

A view can then use those query/events.

Can specs be leveraged for better / simpler error handling and parsing (via conform) ?

Should be status-im/pluto

Setup basic documentation infrastructure based on https://docusaurus.io/. Documentation will be written in markdown, stored in the repo and the final website automatically updated and published in this repo on each commit.

Manifesto and Specs docs should be migrated there.

Implement a syntax allowing to propagate styling/properties to nested view components

Use case: status might introduce visualization for privacy (a chat could switch from private to public). Or some UI might be read-only while others read-write. Those share similarities to theming but differ in an important way: it is not globally set but can be specified at lower scope, multiple times and with different values.

Resources:

• https://codeburst.io/theming-react-components-e0be23465946

Each extension can easily store and retrieve isolated data.
Datomic pull API will be considered. https://anmonteiro.com/2016/01/om-next-query-syntax/

An API allows to register custom queries and events in JavaScript.

How this code will be isolated, what data it access and how changes are propagated will be defined.

The same way view properties are validated

Some resources:

• https://blog.expo.io/announcing-expo-dev-tools-beta-c252cbeccb36

https://github.com/Day8/re-frame/tree/master/docs/EPs

Something similar to what https://github.com/vadimdemedes/ink or https://github.com/Yomguithereal/react-blessed offer for react.

Views syntax should be validated first. Then after parsing result must be valid hiccup.

Events get called with data injected from event caller. Extra data should be considered while validating the event arguments correctness.

e.g. this example is valid as on-change will inject the required value property needed by store/put

[input {:on-change [store/put {:key "input"}]}]

Playground should provide a sumple way for developers to list available components, events and queries.

See https://gist.github.com/jeluard/074d0298f5f4517e62401f445c5f84dd

Currently destructuring does not work for data returned by queries. Make sure it does.

Reference model should be updated to reflect latest @ syntax.

Let blocks replace symbols with their associated values using a dumb logic.

Make sure this logic only replaces symbols that should be replaced (e.g. not view components, blocks symbols, ..).

Also make sure that nested let blocks properly works (shadowing, niling symbols defined in nested blocks, ..)

Structure of the destructuring pattern should match the shape of destructured data (either static map, query or properties).

It might be necessary to introduce meta data for query return value and properties.

Each platform provides a list of hooks and associated meta data they support.
They get back the parsed info and data they can actually use.

Figure out the error model used while validating an extension.
Could be inspired by https://github.com/cognitect-labs/anomalies and https://github.com/dawcs/anomalies-tools

Currently destructured data are not available for further let pairs. Make sure they are.

Finite state machines might simplify creation of complex UIs.

Resources:

• https://github.com/metosin/tilakone
• https://medium.freecodecamp.org/patterns-for-using-react-with-statechart-based-state-machines-33e6ab754605
• https://davidkpiano.github.io/xstate/docs/#/
• https://css-tricks.com/finite-state-machines-with-react/
• https://twitter.com/hillelogram/status/1026608604990918658?s=11
• https://github.com/MicheleBertoli/react-automata/blob/master/README.md
• https://github.com/Day8/re-frame/blob/master/docs/EPs/005-StateMachines.md
• https://github.com/protocol55/step
• https://github.com/davidkpiano/xstate
• https://medium.freecodecamp.org/how-to-visually-design-state-in-javascript-3a6a1aadab2b
• http://raganwald.com/2018/03/03/reflections.html
• https://jonbellah.com/articles/intro-state-machines/
• https://github.com/zaboco/typed-machine

See https://github.com/juxt/edge/blob/master/main/deps.edn

Local events can be defined the same way views can. Only let blocks and string interpolation will be supported.

events/my-event
(let [{param :param} properties]
  [alert "Hey look at ${param}"])

Syntax errors are currently very difficult to resolve. Syntax errors will be the most common experience when people use the pluto and thus these will need to be addressed at some point.

I currently see two solutions to the current situation:

• translating the errors to a concise meaningful message
• providing location info (position in file) of where the error originated

Position info while more difficult to implement can provide more information to a user even if that position information is attached to a cryptic error message.

Position info can be gathered if the edn is read with tools.analyzer on the client.

• pattern matching
• datomic style pull API
• logic programming

Statecharts

https://www.hillelwayne.com/post/formally-specifying-uis/
https://subformapp.com/
https://github.com/davidkpiano/xstate
http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf

Consider adding extra metadata (like localization) tha could be leveraged by hosts.

e.g. vectors and maps

Also add predefined keyword values support

Make sure no TODOs are left