Ahau maintenance / complexity mentoring

Purpose: high level review of current app state,
leading to advice on what to focus on / research,
or gotchas/ code smells

Agenda

• architecture overview
• complexity
• testing

architecture overview

  front-end
    - vue
    - vuex
    - vue-router
    - apollo ---+
                |
                |
-----           |
                |
  graphql API :                                 
  +===============================+
  | @ssb-graphql/whakapapa ---+   |      
  | @ssb-graphql/profile      |   |-------+
  |         |                 |   |       |
  +=========|=================|===+       |
            |                 |           |
  plugins: ssb-profile, ssb-whakapapa, ssb-ahau
                 | 
             --crut--
            /        \
  indexes: backlinks  query

  log: |||||||
  

• database :

  • log: ssb-db,

  • indexes:

    • ssb-backlinks
    • ssb-query

  • record helpers: (using ssb-crut)

    • ssb-profile
    • ssb-artefact
    • ssb-whakapapa

  • general plugins

    • ssb-tribes (group encryption)

    • ssb-invites

    • ssb-friends

    • ssb-conn

    • ssb-replicate

    • ssb-blobs + ssb-serve-blobs

    • ssb-hyper-blobs

• API :

  • ssb-ahau
    • graphql server (federated)
      • @ssb-graphql/main
      • @ssb-graphql/invite
      • @ssb-graphql/tribes
      • @ssb-graphql/profile
        • cache
      • @ssb-graphql/whakapapa
      • @ssb-graphq/story
      • @ssb-graphql/artefact
    • auto-private-profile

• UI

  • Vue
  • Apollo (and vue integrations)
  • Vuex
  • D3
  • Vue router

current areas of complexity

• state management

  • vuex
    • dialogs (modals)
    • notifications
    • selectedProfile in whakapapa tree
    • loading/ manipulating the whakapapa tree
  • apollo
    • query/ mutation mixins
    • cache
      • note there's client side cache + we have server side cache for some records
  • cache invalidation…

• dialog handlers / modals

  • controls which dialog to open

• routes

  • /tribe/:tribeId/profile/:profileId
    • take params.profileId > apollo > getProfile(profileId) > profile record

• graphql

  • meant to be standalone fragments
  • problems
    • @ssb-graphql/main is required core … (dumping ground?)
    • some modules quite dependant now
    • where is that type coming from / who is mutating this type?
    • extending types in other modules

testing

UI/ integration testing

It's really easy for us to accidentally break a feature and not know D:

• e.g. mix broke file uploading
• e.g. somehow image loading on collections+whakapapa got broken

---

Questions

• what are your shining golden examples of patterns you love

  • mixins

• what are the anti-patterns that you'd like to remove

  • things doing raw apollo when there's already a mixin for that.

  • leave a NOTE about why you're doing raw apollo if you are going to?

  • gotcha: mixins sometimes have dependencies (functions they need. make sure to check for those)

• is there anything in vuex that could better be stored in the route?

  • as these are both used for global state
  • which things really need to use vuex?
    • tree > vuex
    • selectedProfile > route? (depends if storing ID or whole profile)

• dialogs

  • easy to design, hard to develop well

    • can have unintended consequences
      • how do you do routing
      • what happens we you go "back" or close a dialog
      • problem for mobile back

  • which things could be pages?

    • dialogs are pages without routing
      • they force you to re-write routing to make it work to flow between dialogs
      • if it greys out the rest of the page it's basically a new page

  • sidebars are cool

    • it's about NOT losing your place
    • if it's not obscuring the page, then it's extending context on current page

  • in our app, it means multiple different things

    • sidebar
    • modal which greys out the screen
      • e.g. confirm delete popup (over another one)
    • page thing

• Mix: how do you hold position on page?

  • matt with patchwork
    • he built a custom router which holds all the pages rendered
    • when you go fwd/ back it hides/ shows
    • if a page hasn't been visited in 5 mins, unload it
  • can record scroll-position
  • router might support it
    • https://router.vuejs.org/guide/advanced/scroll-behavior.html

• state management

  • i.e. database stuff

  • things are calling apollo at:

    • component

    • mixins
      • like:
        • consolidates common state logic in one place (maintenance)
        • this.
          $route,this.$apollo, has access to componenent state
        • can await responses (vuex would have to use some annoying listener)
    • vuex

  • mikey: what are mixins doing that vuex can't?

    • mix: awaiting mixins is easier
    • mikey: can you await a dispatched action? YES: https://vuex.vuejs.org/guide/actions.html#composing-actions
      • e.g. the addPerson method could be a chain of composed actions.
      • this is better than doing lots of state management in a view (which should just be doing presentation)

  • mikey opinions:

    • mixins as a general pattern require on a lot of monkey patching
      • depends on what that object has - implicit deps
        • accessing things via this.* can be tricksy
        • how do you write unit tests?
      • different than functions which import other function - explicit deps
        • explicit is easier/ more well defined
    • vuex should be where apollo happens
      • need a way to inject apollo in
        • there are different modules in the store that will need apollo
    • need one place where data manipulation is happening
    • could use stand along functions which are not mixins (don't have magical context)
    • need to figure out how to pass in apollo to vuex (so it's easier to do testing well)
    • maybe also look at vuex alternatives
      • inject / provide : might be Vue 3 - https://v3.vuejs.org/guide/component-provide-inject.html
    • code smells summary
      • not easy to test
      • deps implicit
      • state management too spread out

  • can await responses ()vuex would have to use some annoying listener

• caching

  • mix describes where caching has been done, challenges
  • mikey: there's a react lib called "stale-while-revalidate"
    • https://github.com/vercel/swr
    • strategy:
      • return stale data
      • start a fetch (revalidate)
      • provide new data when it arrives
    • could have a promise which resolves with { cached, current: Promise }

• Every project is different and whats important is that you have a pattern that works for you

• I've got some feelings about the arrangement you currently you

• Not a huge fan of mixins

• Dialogs force you to write your own router

  • cant easily go back

Testing

Next Steps

• Research

  • async/await dispatch
    • see if you can await things from the frontend
    • see if this returns anything?
  • how to store results ?? vuex state?
  • next:
    • try converting one mixin over to vuex
      • stories
    • write a policy/ guide for how we do apollo/ vuex/ component states
      • makes sure everything else conforms to pattern (or leave detailed notes why it doesn't)

• Dialogs

  • review the dialogs
    • which can be converted to pages (with distinct routes)
      • can investigate vue-router scroll position stuff (see link)
    • which are sidebars
    • which are happily modals