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

Roadmap and discussion for beta release #4

Open
5 of 11 tasks
kMutagene opened this issue Sep 27, 2020 · 0 comments
Open
5 of 11 tasks

Roadmap and discussion for beta release #4

kMutagene opened this issue Sep 27, 2020 · 0 comments

Comments

@kMutagene
Copy link
Contributor

kMutagene commented Sep 27, 2020

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

General:

Backend:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant