Roadmap and discussion for beta release

[kMutagene]

TL;DR - To-Do list for the beta release:

General:

• improve type handling for invokeDynamic, also regarding function argument count (78439fb)
• full support for
  • all core and html components
  • all html components (should be done by Replace Giraffe.ViewEngine with Feliz.Engine for a new Html & Css DSL #15, but needs tests)
• support for multi callbacks (callbacks with multiple outputs): Support multi callbacks #6

Backend:

• Component registry
• inject custom css and javascript sources: Add possibility to add custom scripts/css to the dash app #5
• Improve handling of the Callback type Make Callbacks easier to use and create #10

Frontend:

• Auto-generate components (semi-auto generation is in place)
• PropTypes mapping for auto generate scripts (can be done via Add DSL for Component Properties #8)
• Inline CSS Style DSL

Nice to have:

• full mapping of the dash config
• Error handling
• implement hot reload for improved dev experience
• Server-side validation of objects (is there a JSON schema?)

17/06/2021 - Update

• C# tests, templates, and samples

9/27/2020 - Roadmap and discussion for a Dash.NET beta release

Now that this project is through the proof-of-concept stage (you can check a deployed version of the POC app on heroku here and install a dotnet template for Dash.NET), it is time to open up the development process for external input and maybe/hopefully contributions. For this purpose, i want to summarize the state of the project and highlight issues to overcome for moving it forward. Most of this may be subject to change over time, and i may have missed critical issues, so please feel free to contribute to this issue.

General

Dash.NET is a port of the open source dash framework by plotly, the most downloaded framework for building ML & data science web apps. It should target .NET core only, therefore running on all platforms that support the .NET core environment.

Generally, a dash app hosts a single page react application, containing the DashRenderer and several endpoints that serve JSON which determine the app layout rendered and the callbacks processed by it.

• Familiar look and feel

  When possible, naming/syntax/types should be as close to the original libraries as possible.

• Language support

  Dash.NET is written in F#, but a general aim of the project to be easily usable from both F# and C#, just as Plotly.NET, as well as multiple styles of creating layouts (e.g. the fable react dsl way for F#, as well as providing classes with constructors for components to consume from C#)

• Type safety

  A general problem that showed up pretty early in the design process of this library is that all versions of dash (python/r/julia) are designed for dynamically typed languages.

  This is solved by types inheriting from DynamicObject (this is a tried and tested - as long as correctly encapsuled - way to generate objects with dynamic types to serialize correct JSON in Plotly.NET), and an internal invokeDynamic function to handle callbacks (which are basically functions with arbitrary argument count). We are currently working on making this function more resilient against runtime errors (as both rely on reflection).

Backend:

Dash.Net's backend is built on Giraffe, which itself is built on ASP.NET Core.

• Full Dash config mapping

  Not all config options for dash apps are currently usable from Dash.NET. All options can be found here

• Server-side validation of objects

  Not sure if this is needed in a type safe environment, but all other dash versions do it.

• Component registry

  serve javascript for components based on the referenced component libraries, e.g. only serve html component js when the library is opened or referenced in the project.

• inject custom css and javascript sources

  Adding the option to add custom css and scripts in the header of the dash app

• Error handling

  Implement a type model for dash specific errors, and handle them in a meaningful way (e.g. when a component is invalid, track the validation error and maybe only serve the valid components)

• Hot reload

  Should be straight forward to implement like this

Frontend:

The front end in dash applications is rendered by the DashRenderer from serialized components provided by the _dash-layout endpoint. This is the reason why this is not a Fable based project.
A DSL for dash components and html components has been designed with both C# and F# in mind.

• Auto generate scripts for components

  either as a python script or via a F# metaprogramming tool or generation script that can be called in the dash build pipeline. A really basic script for html component generation is already in place.

• PropTypes mapping for auto generate scripts

  the prop types of react components, as well as everything that is of type object need mapping to F# types for component auto generation to work.

• Inline CSS Style DSL

  A DSL for inline CSS styles must be in place for them to be usable. Seems like the DashRenderer expects these to be key value pairs, which should be possible to be generated analogously to the other types/classes via DynamicObject.