Store records in 'records' key or similar to enable collection metadata for pagination etc.

[jsherbert]

It would be useful to be able to store request meta.

This would open the door to pagination, storing the request order in 'map' mode, a 'busy' flag for fetch operations, etc.

It would require us to store records in a property within the reducer state.

Instead of the state looking like{ ...records }, I guess the dream might be

{
  records: {
    ...records
  },
  pagination: {
    totalResults: 10,
    resultsPerPage: 5,
    order: [1,2,3,4,5,6,7,8,9,10]
  }
  busy: false
}

so we can do something along the lines of

const resultsForPage = selectPage(state, 1).map(id => selectRecord(state, id))

but I'm happy to start with

{
  records: { ...records },
  busy: true
}

Possible concerns:

• Selectors will break, as they'll need to look inside state[reducerKey]records for their records rather than going straight to state[reducerKey]. We can either accept this as a breaking change or introduce the envelope/meta approach as an option and use a selector across the library to get the record list.
• The size of the library will grow, in which case it might be worth thinking about some kind of modular architecture for the non-records meta, but I don't think the refactor I'm proposing will be many lines, it's more likely to be an issue if/when we begin thinking about storing sort order, pagination etc.

What do you think, @sporto, worth a PR?

[hwaterke]

Nothing prevents you from implementing your own reducers next to the ones provided by reduxCrud! IMHO the structure you propose might not suit everybody's need.

Just to give you a concrete example, let's say you want to have a busy flag when fetching.

const busyReducerFor(name) => {
  const actionTypes = reduxCrud.actionTypesFor(name);
  return (state = false, action) => {
    switch (action.type) {
      case actionTypes.fetchStart:
        return true
      case actionTypes.fetchSuccess:
      case actionTypes.fetchError:
        return false
    }
    return state
  }
}

const reducer = combineReducers({
  records: reduxCrud.Map.reducersFor('users'),
  busy: busyReducerFor('users')
})

[jsherbert]

@hwaterke, yeah, you're absolutely right, it's probably best to keep redux-crud as a smaller library and add functionality as needed. I can imagine package size/complexity spiralling as new functionality is added and differing use cases stretch the API.

Thanks for the example :)