Captain's Log

[gregorykan]

According to lore, the three-masted schooner was found west of Greenland by the whaler Herald on 11 October 1775. The boarding party took only the captain's log before leaving the vessel, because they were unwilling to search it. The last entry in the log was from 11 November 1762, which meant that the ship had been lost in the Arctic for 13 years. As the log was frozen, it slipped from the binding, leaving only some of the pages in it. All that could be recovered follows.

[danalexilewis]

Chuckles - very good :)

[gregorykan]

Here are some of the things I found challenging on this ship so far:

• Initially it was hard to know 'where the backend is' (lol if you know what I mean)
  • Have a look at the feathers-actions docs and those of the related libraries; have a look at the server.js and services files
  • Still unsure about non-CRUD endpoints?
• Getting used to feathers-actions doing so much
  • This is purely a conventions thing; same as above - read all the docs/examples
• Not knowing how to divide labour between feathers-actions/hooks and redux-observable
  • Not super sure about this still?
• Getting used to this particular 'shape' of container
  • Not actually that hard when you look at the keys; it makes sense; everything that you could have in the 'traditional' container is there too
• Not knowing what was already part of dogstack-agents
  • Just had to read the docs: https://github.com/dogstack/dogstack-agents
• Getting my head around ramda
  • This takes some understanding of higher-order functions, currying etc.
• Getting my head around recompose dumb components
  • Again, not that hard when you look at the docs and have something to reference
• Getting used to redux-fp and its updaters
  • Look at the doooocs
• Took me a little bit to get my head around the task flow (i.e. TaskWorker/TaskStepper) implementations
  • Mostly this was because @ahdinosaur was still working on it; there wasn't a complete example quite ready; with some documentation and an example this would not be an issue
• It's quite hard to conceptualize and abstract robust models for offerings and intents, let alone building good (UI-wise) forms for them
  • This is an ongoing set of questions that will probably require a lot of user feedback/testing

[michael-smith-nz]

This is great. Used it for the first bullet point already :grinning:

[michael-smith-nz]

I found looking at the migrations in db/migrations a good to way to find what is actually being stored in the database.

[ahdinosaur]

re https://github.com/root-systems/cobuy/pull/120/commits/656dda9eb8e1aa5adb452ce37f260e684497b9a7

updates for how we do container queries:

• https://github.com/ahdinosaur/feathers-action/pull/19
• https://github.com/ahdinosaur/feathers-action-react/pull/3

the problem is we want to make it easy to declare what data you need for your component, but sometimes queries depend on each other having been complete before you do another. so far i'm trying an approach with a query(props) => queries and shouldQueryAgain(props, requestsStatus) => Boolean, not sure if it's the right idea but it works for now.

the change i made was to have each request have an isReady state, which is updated by an action fired after a response has been returned by the server. the reason we couldn't tell if a request was ready or pending before was that by default, all requests are persistent and listen to any changes as they come in live, so it always seemed like all requests were pending.