Feature Scope

[upsiflu]

The trajectory goes towards reducing the number of Msg that the user application needs to handle -- down to only those that actually modify the domain model.

One by one, concerns are offloaded to the less-ui library:

Cohesive views

• [x] Layout with Global regions -- no more needlessly nested components

Typical State-in-Url patterns

• [x] Ui fragment Progressive Disclosure -- Toggle

• [x] Ui fragment Ad-hoc page paths -- GoTo and Bounce

• [x] Contingent Ui fragments -- Filter, Search

  • [x] Implement patterns
  • [x] Try to defunctionalize the type

Ui state that doesn't map perfectly to the Url but shouldn't be handled by the app

• [ ] Focus and Viewport position

  • This one is ultra hard. Hello Web platform. Can we ever embrace the messy state instead of fighting it?
  • Is there a standard for storing navigational state in the Url, akin to ?xy=0,20879?
  • How to trigger the elm runtime but not a reload, when I change the hash, path, assignments and flags with custom-elements?
  • [ ] Scroll to change Url (via custom element or task). This is an uncommon pattern but I unreasonably like it.
  • [ ] Something like "Am I visible?" would be an amazing functionality to have. We can build on the atLocation : (Location -> Ui ) -> Ui interface and create something like byViewportOverlap : (Float -> Ui) -> Ui where the float represents the overlap (if the element is just out of the screen, the float is 0; the further it moves away, it becomes less than zero. The magnitute 1 matches the size of the element; the closer the element is to the screen center, the larger the float grows above 1. For example, on a screen with dimensions 3x3, an element of 1x1 tucked to the left border yields 1, centered 2, outside of the screen with a distance of 1, -1, half-visible 0.5).
  • [ ] Give the scroll position to css so that we can work some magic

• 28

• 8

• [ ] Pointer and keyboard interactivity

  • [ ] Drag'n'Drop (see https://ellie-app.com/7TTxFRNPDGJa1)
  • [ ] Draw what you want to do directly on the screen (or touchscreen) like it's 1968
  • [ ] Cancelling every press, drag, draw, modal, background task... with ESC (bringing 80s WIMP tech to the Web!)
  • [ ] Hotkeys for toggles (Hello productivity & Game apps!)

Auto-deriving a View from a Model

• [x] Model Subtype preconfigurations

  • Define your Model as and Elm-in-Elm type or as a List of Actions where each Action compounds a state and certain states prohibit certain actions
  • You have a central store (elm-store iirc?) for these Actions, which you read on each view
  • Restrictive.Model then derives:
    1. Global and local undo+redo
    2. A Codec to store all subtype preconfigurations in the Url. For example, you have a Maybe String. You set it to Just "xy", then to Nothing. What you want is a button/switch to bring you back to Just "xy" (instead of Just "" which would be really lame). This functionality can either be provided by storing a tree of already-populated constructors for the author's Model, or to derive this tree from the previous Actions.

• elm-any-type-forms solves this:

• 22

• 28

[upsiflu]

In the long term, Url stores all Ui/Ux state while an offline-first and/or remote store is the definite source for the model. -> No more volatile state (The app is practically a stateless definition of the model and the possible interaction patterns)

• 29