Add Fastboot Notes for 2020-11-20

fastboot-team/2020-11/2020-11-20.md

@@ -0,0 +1,82 @@
+## Agenda
+
+*This week:* 
+
+- (public | private) (**5 min**) <agenda item> (<presenter initials>)
+- [https://github.com/ember-fastboot/fastboot-express-middleware/pull/66](https://github.com/ember-fastboot/fastboot-express-middleware/pull/66) - ready for merge/review - (SD)
+- (public) continue discussing monorepo setup
+    - ember-cli-fastboot-testing - should we merge it in?
+- (public) Discuss the current state of world around rehydration/TTI - (SD)
+
+## Attendees
+
+- [x]  Chris Manson (CM)
+- [x]  Robert Jackson (RJ)
+- [x]  Dave Laird (DL)
+- [x]  Suchita Doshi (SD)
+- [x]  Thomas Wang (TW)
+- [ ]  Mark Pascual (MP)
+- [x]  Scott Newcomer (SN)
+
+## Minutes
+
+- discussing the fastboot-express-midleware PR
+    - writing the tests are easy, but setting up the fixtures are quite hard
+    - TW: I might have done something in the monorepo that might help with this
+        - [https://github.com/xg-wang/ember-cli-fastboot/blob/monorepo/test-packages/integration-tests/test/basic-test.js](https://github.com/xg-wang/ember-cli-fastboot/blob/monorepo/test-packages/integration-tests/test/basic-test.js)
+    - current fastboot test suite doesn't work with the current ember-cli-fastboot
+        - needs a dummy request response
+        - RJ: we can't assume that we have request response
+        - this can be consumed in contexts that don't have requests
+        - TW: I added a todo in my work to look into it
+    - RJ: it would be nice to have 2 sentences of how to setup the "old way" of testing
+    - but we should probably invest our effort into the "new way" of building an app rather than relying on a random vendored built app
+    - yay for TW's work 🎉
+    - TW: you might want to do a quick copy-paste into the monorepo to check interop issues that we might have
+    - DL: I see our tests mostly leveraging a single app that can have routes that we need
+    - RJ: unless we're doing something fundamentally different (embroider etc.) then yes
+    - we want to keep the "default" app quite simple. It can cover happy path cases
+    - DL great example: a new test app to test fingerprinting config: [https://github.com/ember-fastboot/ember-cli-fastboot/pull/803](https://github.com/ember-fastboot/ember-cli-fastboot/pull/803)
+    - merged 🎉
+- monorepo setup conversation
+    - gist with the plan: [https://gist.github.com/xg-wang/f60c6aa01c3d1d64a794518be520bd01](https://gist.github.com/xg-wang/f60c6aa01c3d1d64a794518be520bd01)
+    - discussion of what has been done already
+    - TW: we will need to create a script to do the release
+    - RJ: myself and DL created a script we can use to do the release
+    - CM: we need to make sure that we keep all the history of the different packages
+    - RJ: we will verify this
+    - TW: we discussed that we would start with a blank repo but it was easier/better for us to **start** with ember-cli-fastboot
+    - TW: renaming ember-cli-fastboot to ember-fastboot/ember-fastboot will maintain links and history and setup
+    - RJ: things that must work:
+        - git log needs to
+        - git blame for a file
+        - contributors list on github is a superset - this seems to work 🎉
+    - TW: I will create a PR so we can start to give feedback
+    - RJ: the PR description needs to explain to the wider community what is going on!
+- rehydration TTI
+    - where are we currently and get some history
+    - CM: where does this sit in the Deep Dive Topics?
+    - RJ: there are some things to get to the topics like "turn on rehydration by default"
+    - we probably need to remove the "experiment" flag/terminology, stop people feeling like they're doing a bad thing by using it
+    - right now there are some odd interactions between the "fastbooted" app and the rehydrated app
+        - e.g. if you are using an input then it is intractable once the HTML has loaded
+        - when the rehydrated app loads then it will instantiate a component that has no idea of the internal state of the form element
+        - we talked about this in the last season of fastboot calls
+        - we were working on a dive-in to render inputs (or all form elements) as disabled until the app boots
+        - SD: there is a set of things that won't work without the ember app
+        - RJ: yes that's correct
+        - DL: we need to think about the tracking of the user. not specifically "page views" but things like "where the user is clicking in the app"
+        - a lot of these issues might be minimised if we can load a small payload in the first place (things like embroider)
+        - RJ: this is always be a race condition
+        - interacting with links will be fine because page views are fine
+        - for other kinds of interactions you can theoretically deal with (like has an element scrolled into view) by having a small app that just deals with small interactions. This is likely hard to implement and might be a waste of time in general
+        - CM: but if we are disabling interactive elements then this is less of an issue no?
+        - RJ: yes, but we need to make sure that our system doesn't make it impossible (which it doesn't)
+        - DL: in general the faster our ember app loads the better all of these cases are, so we should do everything that we can to help with "upstream" things
+        - DL: in our last season of calls we discussed tracking where rehydration actually fails
+        - SD: if we could split the app to just what is visible in the viewport (based on components) this would help the situation
+        - RJ: there are tests in GlimmerJS for this
+        - we would need to leverage embroider to even be able to do this
+        - we would need to make this more ergonomic
+        - CM: propose that we create a "deep dive topic" for "Make Rehydration Ergonomic" that covers getting this working in general
+        - [Make Rehydration Ergonomic](https://www.notion.so/Make-Rehydration-Ergonomic-8da207c36a8d431c9e0cdd0e9c623926)