Skip to content

Frontend cleanup #1348

@georgefst

Description

@georgefst

As the new frontend moves from an experiment towards, let's say, alpha quality, we ought to start bringing it up to the standards of the rest of the codebase. This issue serves to collect such concerns in one place. We'll likely solve some of them soon and open separate issues for those which are less trivial.

See #1341 (comment) for background, plus other threads in that PR review as well as #1346.

  • Improve comments.
  • Avoid error.
  • Warn on unexpected behaviours.
  • Ideally upstream everything in Primer.Miso.Util. At least move the Primer stuff in to primer or primer-api, and split the rest in to more specific modules or packages.
  • Implement a better form of persistence. Storing the app in local storage with startComponentWithSavedState has worked remarkably well, but it was only ever really intended as a bit of a hack to help with a hot-reloading-like workflow.
  • Do some basic profiling and optimisations. I expect there to be a lot of low-hanging fruit here.
    • For example, currently the app gets pretty sluggish when the number of actions run gets in to the hundreds. This can be mitigated for now by reloading after running localStorage["miso-app-state"] = JSON.stringify((m => (m.app.currentState.prog.progLog.unlog = [], m.app.initialState = m.app.currentState, m))(JSON.parse(localStorage["miso-app-state"]))) in the browser console, though obviously this breaks the ability to undo older actions.
  • Split some code in to separate modules. Miso.hs is now 1000 lines long, making HLS and live reloading noticeably sluggish. The obvious way to split would be by component, in which case we should perhaps wait for the next release of Miso. EDIT: or use HEAD: Use Miso HEAD #1357
  • There are various small missing features, which are obvious from using the app for a few minutes. @dhess has expressed in interest in implementing some of these as easy first contributions to the new frontend app. The list below is not intended to be exhaustive.
    • Add buttons for adding and removing definitions, including type defs.
    • Grey out undo and redo buttons when we're at the beginning or end of history respectively.
    • For the eval options, we should probably choose some sensible defaults and put the controls behind an admin/debug flag, like whatever we end up doing for showIDs. We should experiment with the various options first: my impression so far, with the options we use in tests (grouped lets, aggressive elision, push and elide) as that we spend quite a lot of time fiddling with lets in branches that ultimately don't matter.
    • Things which haven't been implemented from primer-app. These are either because they're more difficult to implement without library support (React Flow and Tidy), because the UI/UX may need a rethink, or both:
      • Better layout, e.g. with a modification of the Tidy algorithm which directly supports horizontal children for patterns and bindings.
      • Curved tree edges.
      • Edge labels.
      • Modes other than "expert".
      • Use human-readable text for action buttons instead of the Haskell constructor names.
      • Better display of global names. Currently we just use globalNamePretty, which means using a dot to represent module qualification.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions