materialsproject/crystaltoolkit

General issues

mkhorton opened this issue · 0 comments

This issue is a placeholder for more specific issues to be added.

A few features in Dash 2.x might help remove certain pain points in the Crystal Toolkit design, and older decisions should be revisited.

Specifically:

  • Adopting formal multi-page support (although; this needs to be benchmarked for e.g. 100k+ pages, or a hybrid page + query parameter approach might be adopted).
  • Removal of the global list of dcc.Stores (see here).
    • This approach was an error for large, multi-page apps. Instead, the MPComponent's respective dcc.Store should live with its layout.
  • New Dash component templates might provide an alternative to the MPComponent design.
  • Ensure any client-side callbacks are in a dedicated crystaltoolkit.js file.
    • The current approach drops the callbacks into the main HTML template. This is not ideal and quite messy!
  • Use pattern-matched callbacks throughout all MPComponent if possible; this would avoid use of register_callbacks() entirely and further simplify the design.
  • Audit best practices in the Dash community to see if any other changes should be made.
  • A guiding principle is if we can remove features from Crystal Toolkit, in favor of first-party supported options from Dash or elsewhere, then we should (likewise, if certain features would be better upstreamed to pymatgen, such as plotting improvements). It's ok to remove code and make Crystal Toolkit leaner and simpler over time.