effa
commented
8 years ago Example of decorator to extract values from state to function parameters:
@extract_state(tasks='entities.tasks') Question - how to call the decorator, extract_state, extract_params, state_params? How about testability?
How to organize state (current dot notation feels strange). Should meta (id, parent_id, version) and context (time, randomness_seed) be part of each action? Why: because it changes often (at least time) and maybe it could allow for easier merging (rebasing?) Meta vs. context? (should we even distinguish these two and where does version belong? Are entities the only data? How to deal with context being part of both a state and an action. Should reducers, extractors and task_creators take full state/action or just parts (for example data and context). And would it be useful to write decorators to extract state/context/data to specific arguments and how it should work? (
@extract_state,@extract_data). When/where should we bind meta information and context and data to action/state before passing to the reducer/extractor/store?We should precisely define what we mean by data (entities), context and meta information. We might want to consider some convention such as always mapping entities on the entities in DB (or static data?) and context to a computed values.
Related question 1: how to represent context (dict + utilities in context.py +
@extract_contextdecorator, vs. class Context with useful properties or a namedtuple).Related question 2: action creators - module (functions) vs. class (static methods) + suitable names, parameters: should they take state, or just context and meta, should we extract parameters from state/context/meta.