Sprint Plan

[dchambers]

Spike 1 (Week 1):

Add support for nodes (1d), node-lists (1d), property-specifiers (1d) forced notifications (0.5d), handlers (1d) and partially specified handlers (0.25d):

• [ ] composerjs.create()
• [ ] p()
• [ ] node.props().resolve()
• [ ] node.addHandler(handler)
• [ ] node.addHandler(inputs, output, handler)
• [ ] node.define()
• [ ] node.set()
• [ ] node.get()
• [ ] node.addNodeList()
• [ ] model.seal()
• [ ] model.notifyListeners()
• [ ] nodes.length()
• [ ] nodes.item(index)
• [ ] nodes.addNode(index)
• [ ] nodes.removeNode(index)

  Spike 2 (Week 2):

Add support for sealing feedback (0.5), nodes (1d), specialized types (1d) and self-referential data structures (1.5d):

• [ ] model.seal() (sealing feedback)
• [ ] node.addNode()
• [ ] node.addDisabledNode()
• [ ] node.exists()
• [ ] node.create()
• [ ] node.dispose()
• [ ] nodes(specializedType)
• [ ] node(specializedType)
• [ ] node.defineAs()

  MVP (Week 3):

Add support for change listeners (0.5d), mutation listeners (0.5d), beforechange listeners (0.5d), handler constructors (1d) external handlers (0.5d) serialization (1d) and mix-ins (0.25d):

• [ ] node.on('change', ...)
• [ ] nodes.on('mutation', ...)
• [ ] model.on('beforechange', ...)
• [ ] node.addHandlerConstructor(handler)
• [ ] output.hasChanged()
• [ ] model.export()
• [ ] model.set(json)

  1.0 (Week 4):

Add support for property-specifier filters (1d), specialization introspection (0.25d), specialized handlers (0.5d) & quality assurance (3d):

• [ ] node.props()...
• [ ] node.nodeType
• [ ] node(nodeType).addHandler()
• [ ] quality-assurance of all features (I propose that we don't involve a QA until sprint 4 to reduce any on-going communication overhead)

[dchambers]

@james-shaw-turner, here are some preliminary sizings and a sprint plan. This assumes that I'll have no other interruptions, which either means I'll actually be working much longer hours, or that I may also work from home some days, so I can avoid interruptions.

The first two sprints are all about de-risking, followed by a sprint that introduces the remaining features people would need to be able to release with, followed by any bells and whistles last. This would allow us to start making tentative use of the library after two weeks, and making almost complete use of all features after three weeks.

[adamshone]

@dchambers There isn't anything in this sprint plan about spiking an actual useful component (e.g a ticket or tile) based on the new model, and I think we need to do that first before building the whole thing. If we write a full example and it turns out to be ugly or complicated then it will require changes to the model.

[dchambers]

Hi @adamshone,

Yes, the sprint plan presented here is for developing ComposerJs rather than designing it, on the basis that we won't start writing any code until we're happy we've got the design right.

There are already simple spikes of both a tile and a ticket, though these aren't yet as complex as the one in the FX motif, nor do they deal with the view-model semantics.

Now, as it happens, yesterday I started a new effort to define a catalog of handlers that can be used to allow every tile and ticket we've ever created to be built through composition. I'll be sharing the design and any code snippets within a new stash repository in due course...