Implement Markdown Backend (Stage I)

[upsiflu]

Markdown package: https://mweiss.github.io/elm-rte-toolkit/#/examples/markdown An editor with customizable spec

Combined Parser/Printer package: https://elm.dmy.fr/packages/lue-bird/elm-morph Safely convert between narrower and broader types

To Do (Stage I)

• [x] Accordion is its own list of Actions and is rebuilt on every view
• [x] Replace Html.Styled by Html.Keyed as far as possible (use toUnstyled early)
• [x] Accordion ViewMode is implemented as restrictive Url flags
• [x] Remove Templates and make initial tree only the Home segment
• [ ] Replace the Codecs with elm-multitool:
  • [ ] 1 model type, including the accordion and its nested articles (including the markdown)
  • [ ] 1 value type codecced with elm-serialize (for simpler codecs and smaller json than elm-codec)
  • [ ] 1 form for everything. (Does Restrictive.ui allow several controls to render regioned Ui?)
• [ ] Replace the HTML editor with elm-rte
• [ ] Update the firebase custom-element to just store and retreive the whole single document. Firebase will do smart partial upgrades over the wire anyways.
• [ ] Using the app, re-write the Templates as Markdown (again, Article template in frontmatter)

type Model
    = Loading
        { maybeZone : Maybe ( String, Time.Zone )
        , maybeNow : Maybe Time.Posix
        , maybeAccordion : Maybe Accordion
        }
    | Model
        { accordion : Accordion
        , zone : ( String, Time.Zone )
        , now : Time.Posix
        }

type alias Accordion =                    --New!
    { history : List (IntentId, Action) }

type Action
    = Name String
    | Modify Article.Action
    | Go Direction
    | Insert Direction
    | Delete
    | Reset String
    | Undo IntentId

type alias Accordion.ViewMode                    --New!
    = Viewing
    | Editing { viewingHistory : Bool, viewingMarkdownSource : Bool, viewingTemplates : Bool }

type alias Article =
    { id : String
    , caption : { text : String, showsDate : Bool }
    , info : Maybe InfoChoice
    , body : BodyChoice
    , shape : Shape
    , fab : Maybe Fab
    , additionalClasses : List String
    , body : Markdown                             --New!
    , templateArticleId : String            --New! Will serve as initial data in case the article cannot be found
    , directives : List (String, String)      --New!
    }

App Lifecycle:

1. Download accordion and find out the current time and timezone
2. view:
   1. Navigate to the current place
   2. Draw the Accordion
   3. Segments that are in view:
      • Is Article cached?
        • Yes:
          1. If it has an articleTemplateId, and we are previewing templates, -> view the template article instead
          2. Draw the Segment with the corresponding Article
        • No: Draw a placeholder.
      • In any case, the Segment also draws a custom-element that listens to remote changes.
3. update:
   • A new accordion version has arrived (locally ore remotely): replace the Accordion
   • A new article version has arrived (locally ore remotely): insert it into the Articles dict under its .id
4. directory:
   • Find result within in the list of articles
     • If article is not loaded, it's just the self-string
     • If article is loaded, insert its own directives

Stages

Stage I

• Last-write-wins; single version, online-only
• Article is represented as markdown content; Segment is represented in corresponding md frontmatter as a series of Intents
• Accordion is represented as a series of Intents
• Accordion and Segment will condense their series of Intents into a single string

Stage II

• Intent series are condensed on write
• On each overwrite, the custom element creates an 'older version' diff and stores it in an additional document: {id}.history (a series of (date, diff)) replaces {id}.template
• You can browse the versions

Stage III

• Switch to rxbase

Stage IV

• Base the for date selection on elm-rte-toolkit/#/examples/spec-from-scratch