Jeff: Refactor inspector & factory. We should have docs to instantiate inspectors. We will need to do more of this (such as for local charm work). We can also make some nicer factories. Rick: agree. Gary: a day to make better docs and a nicer factory sounds reasonable for now, but I question whether it’s the right prioritization to do more refactoring. Jeff: We will need it for machine view. Rick: Yes. So let’s do that bigger refactoring when we need it. Gary: We don’t need the bigger refactoring for local charm work, right? Jeff: Right. Resolution: Jeff will add a card in the local charm lane for a small doc/factory improvement, and we note that we will need inspector refactoring for the machine view effort.
Benji: Sidebar auto open/close postmortem. Getting the prototype done was easy and fast. Getting the tests done was difficult and slow. I’m afraid the difficulty of writing tests is snowballing. Discussion points include test friction, architecture visibility, architecture enforcement. Rick has an idea of dividing the application into layers which might help; if we do that then we should automate the limitations. Jeff: I agree. When I spoke with Ben about architecture a while ago we agreed that we wanted layers but we didn’t agree on a transportation layer. Therefore the layer idea didn’t develop as well as it should. Benji: Right. To clarify the ideas of layers, upper layers can communicate directly down, but not reverse. Jeff: Yes, that’s worked for me in the past. Rick: Further to Benji’s description of what I want from layers, upper layers only talk to layers *immediately* beneath them. If upper layer A connects to lower layer B which connects to lower layer C, then A should only talk (and hear directly from) B. Benji: Jeff, could you unpack the idea of a transportation layer? Jeff: […sorry secretary was typing and lost the content…]. Benji: Can we agree on layers and then move to a separate discussion on what we communicate and how? Gary: If we don’t agree on what we are communicating, we might not agree enough on what a layer is, but let’s give it a try. 🙂 […Lost discussion…] Rick: Rather than talking about layers, we can talk about who owns what. The app layer owns the environment view. Therefore if the inspector needs to make the environment view get smaller, then the app needs to learn of this requirement, and then communicate it to the environment view. Jeff: Transport layer is possibility to move away from events and still get layers. Chrome events might help. Rick: I’d like to see if we can have experiments to make debugging events easier. Gary: [Says stuff advocating using functions as the standard, and events as the exception.] Francesco: It worked well in quickstart and GUI charm. Maybe the distinction is that external interactions (websocket, UI calls) are events and everything else is functions. Rick: What Gary is advocating is similar to what I’m proposing. [Gary nods] Jeff: Passing a function down that gives functionality is unusual for JS; callbacks that alert is more common. If we want to take these patterns then we should agree. Matt: agree, similar to Promises. Gary: Except promises are viral. Rick: […Comment lost…] Benji: […Comment lost…]. Rick: Pre-imp call would help make this happen. Gary: Will create retrospective card for discussion two weeks from tomorrow. Gary will be out that day. Goals will be to agree on a first cut of the communication mechanism (events, functions, ?) and on what the impetus will be to cause the changes to occur gradually and regularly (pre-imp, or Benji’s automated “ratchet” mechanism like the documentation tool we have, or something else or in addition).
Rick: makeContainer autocleans. pattern: hooks into afterEach, make sure you clean up your objects. Needs the test context. pushes callable onto cleanup stack. See makeContainer for pattern if you want to make your own autocleaning code. Gary: switch from FIFO to FILO for running cleanups? Rick: Agree. All: YAY on autocleaning makeContainer!