Mark tile fn functions with some marker to ignore other function actions

[amityagov]

Hi

How about to mark fn functions with special marker so middleware will ignore other actions like redux-thunk actions?

I have problem with using tiles with thunk middleware. And i have no chance to rewrite existing thunk-based actions).

Example code

if (typeof action === 'function' && action[TILES_ACTION_FUNCTION] === true) {
    return action({ dispatch, getState, promisesStorage, ...paramsToInject });
}

So you need to mark these functions in createTile method or something.

Thanks

[Bloomca]

Hi!

Thanks for your interest.
The problem here is, that if we do something like this, we'll have to put tileMIddleware before thunkMiddleware, and I don't like it personally. But you are right, I was assuming one will use one middleware or another, but not together.

I will research, maybe I can just return an object with some mark property, and with a function; but I'll take a look at the most popular middlewares first.

For now, you can use only thunkMiddleware, with additional-parameter:

import { applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
const middleware = thunk.withExtraArgument({ promisesStorage: {}, actions, selectors, api });
applyMiddleware(thunk, ...);

promisesStorage is needed for caching (so you can await already processing async tiles with caching), but you can omit it.

Thanks,
Seva

[Bloomca]

I looked into it, and seems there is no standard way to differentiate middleware (e.g. if it will process functions no matter what). On the bright side, redux-thunk and promise-middleware are beyond everything else, so it is possible to write only a specific thing instead of redux-thunk. It is not very good, though, because there is a possibility of custom middleware, so I think the best solution would be to return an object of similar structure:

{
  type: SOME_DUMMY_TYPE_IN_CASE_SOMEBODY_INTERCEPTS_HERE,
  SOME_SPECIFIC_REDUX_TILES_KEY: true,
  fn
}

This should not cause any issues, because all middlewares I've looked into look for promise in action.payload or just invoke a function if it is passed.
So, exactly as you proposed, but using an object (otherwise, as I said, order will matter).

Maybe you know some caveats regarding this approach?

[Bloomca]

So I believe this is a good solution – middleware will be independent from any other middlewares; it will require separate test suites though, with different sets of middlewares together, in different order.