richburdon
commented
7 years ago This is a big refactoring of Item rendering, provoked by major changes in Apollo to fragments. DetailView is now a very simple non-HOC container that provides some chrome around items and cracks the properties (item ID) from the router. Item types now control their own queries: which include the base Item's fragment and their custom fragment. Each type defines: its fragment, an outer card component, a dumb type-specific layout component, and a HOC that uses a common composeItem(query)(container) function (similar to list_factory). This provides a nice Lego-set. I.e., DetailView can just dispatch to the Item HOC, and other views/cards can reuse the "dumb" type-specific containers. NOTE: Component inheritances was assiduously avoided (over composition); i.e., the type-specific container uses composition to squirt itself into the generic ItemContainer. NOTE Also: the type-specific wrapper now has a firm contract to provide an onSave callback to gather mutations when the parent ItemContainer is preparing to save. NOTE: createFragment warnings are generated by apollo in-flux and can be ignored until 0.6 NOTE: This also removes the static (singleton) dependency on the TypeRegistry (since it is no longer needed to construct queries (i.e., provide fragments). This is a HUGE benefit and clean-up. TL/DR: defail.js, item.js, registry.js, task.js
Trying to factor out the basic List component (hopefully moving to minder-ux) from the HOC components, reducers, fragments, etc.
Relates to: https://github.com/alienlaboratories/react-demos/issues/26
Apollo fragments still quite unstable.
Goal is to move inline editing into the list also.