trigger action at begin of async main alias action

[rsaccon]

My aliased actions (main process) are async and need some time to fulfill. The state change occurs when the action has fulfilled, and I am fine with that of course, but I would also like to have an additional state change at the begin of such an async action (for progress indicators and disabling buttons while the main async action is executing). Right now I am just using an additional sync action for that. Does there exist a way to bake in such an additional action into the alias action ? That would reduce boilerplate code for this type of usage pattern.

[hardchor]

There's different approaches to this.
https://github.com/acdlite/redux-promise (the one I'm using in timesheets) only triggers an action once the promise resolves (or rejects), making optimistic updates, loading messages etc. difficult. The way we worked around this in an unrelated project is to always assume a resource to be loading until it resolves, e.g.:

// reducer
const initialState = {
  userData: {},
  isFetched: false,
};

function myReducer(state = initialState, action) {
  switch (action.type) {
    case FETCH_USER: {
      // fall back to previous state on error
      if (action.error) return {...state, isFetched: true});

      return {...state, ...action.payload, isFetched: true};
    }

    default:
      return state;
  }
}

export default myReducer;

Also check out the discussions redux-utilities/redux-promise#12 and redux-utilities/flux-standard-action#7.

There's also https://github.com/pburtchaell/redux-promise-middleware, which does seem to trigger separate actions during loading, but I've never used that, nor tested it against electron-redux (but can't see why it wouldn't work).

[hardchor]

Looks like npm i -S redux-promise@^0.6.0-alpha has support for optimistic updates as discussed

[rsaccon]

Thanks a lot. redux-promise-middleware looks interesting or "promsing", will give it a try later and report back here. About redux-promise@^0.6.0-alpha, is that the sequence branch ? If so, little development there lately, but I might be mistaken.

[rsaccon]

Ups, yes, it is the sequence branch. Will try that as well.

[hardchor]

It's actually in master. I wouldn't judge redux-promise by its activity, though. The Promise interface has been stable for a few years now, so there's not much reason for change. If you do end up playing with redux-promise-middleware, please let me know how it goes.

Out of curiosity, what are you building?

[rsaccon]

I just tried redux-promise@^0.6.0-alpha. It doesn't work (yet). On the main thread, the promise actions created with createAliasedAction look as expected, but they do not show up on the renderer thread. I guess, because the format of the actions now is a bit different, two actions in sequence. If i use simple, non-promise actions, the continue to work as before. Will need to look closer into it later, but maybe you have right away an explanation why they do not get replayed on renderer.

About what I am building, it is static site generator, to be used by non-technical folks, therefore all baked into electron and only a Prosemirror editor exposed to the user. But it is not usable yet ...

[ghost]

No, that seems strange. I've added some debugging to the middleware in the redux-thunk ticket. If you run your electron app with DEBUG=* npm run dev (for the main process) and run localStorage.setItem('debug', '*') in your renderer's devtools, do you get any warnings from electron-redux?

P.S.: Substitute '*' with 'electron-redux:*' to reduce noise.

[rsaccon]

ok, here is what I get at the main process:

Thu, 03 Nov 2016 10:58:33 GMT electron-redux:validateAction Action not FSA-compliant { type: 'GET_PROJECTS',
   payload: undefined,
   sequence: { type: 'start', id: '2' } }
 // console.log(action):
 { type: 'GET_PROJECTS',
   payload: undefined,
   sequence: { type: 'start', id: '2' } }
 action @ 17:58:33.193 GET_PROJECTS 
 —— log end ——
[1] Thu, 03 Nov 2016 10:58:33 GMT electron-redux:validateAction Action not FSA-compliant { type: 'GET_PROJECTS',
   payload: 
    [ { id: 'goooo', type: 'project', title: 'Goooo' },
      { id: 'third', type: 'project', title: 'Third' } ],
   sequence: { type: 'next', id: '2' } }
 // console.log(action):
 { type: 'GET_PROJECTS',
   payload: 
    [ { id: 'goooo', type: 'project', title: 'Goooo' },
      { id: 'third', type: 'project', title: 'Third' } ],
   sequence: { type: 'next', id: '2' } }
 action @ 17:58:33.198 GET_PROJECTS 

I guess, this explains it: validateAction is too picky! But would it work without validateAction ?After all, this comes from the people behind the FSA definition (I think). Or am I using it in a wrong way ?

Ups, just checked about FSA:

An action MUST NOT include properties other than type, payload, and error, and meta.

so, this sequence props are not FSA compliant, they should be in the meta property

P.S.: I just read the discussions to make the sequence stuff part of FSA, which happened more than a year ago. Maybe better to give https://github.com/pburtchaell/redux-promise-middleware at try next, hoping it will just work out of the box ...

[ghost]

Yeah, looks like sequence was implemented as a top-level parameter: https://github.com/acdlite/redux-promise/blob/sequence/src/index.js#L22-L25

That does obviously break FSA specs (which is slightly surprising), and hence validation doesn't pass.

Let me know how you get along with redux-promise-middleware

[rsaccon]

after adding redux-promise-middleware, no actions got dispatched anymore, neither promises, nor non-promises. And nothing got logged. No idea why.

[hardchor]

I've played around with redux-promise-middleware in hardchor/timesheets@596ecc1 and it works fine, but there are a few gotchas:

• You can't dispatch un-aliased promises to main (because they get sent via IPC and Promises can't be stringified)
• If you need local promises (i.e. ones that only live in a single renderer), you need to set meta.scope = 'local' (https://github.com/hardchor/electron-redux#local-actions-renderer-process) *

* this will rarely be the case, but is worth knowing

[rsaccon]

ok, now I see what I did wrong, registered the middleware as promise, but in your code it is as promise(), so I will give it another try later.

[rsaccon]

It all works now perfectly with the promise middleware, thanks again, gonna close this.