Flow types

[steida]

Does anybody is working on that?

[jayphelps]

Not as far as I know. If you make solid ones, we'd definitely love to have them included! ❤️ One important thing is that to provide any meaningful type definition for redux-observable you actually would also need a type definition for rxjs. I see there are some here https://github.com/flowtype/flow-typed/tree/master/definitions/npm/rxjs_v5.0.x but I haven't personally tried them.

[steida]

Why? Flow types can be spread aka ...

[jayphelps]

@steida sorry, I don't understand the question?

To clarify what I meant: redux-observable is really small duct tape between redux and rxjs, so the API surface you interact with is mostly rxjs itself (other than the setup stuff like createEpicMiddleware). We provide an ActionsObservable, which extends Observable. To type it you'd need to have the type definition for Observable. To type any of the rxjs operators you use, you'd need full rxjs type definitions as well.

[steida]

Is it sure that rxjs flow types can not be reused & extended?

[jayphelps]

@steida you do not have to duplicate rxjs typings. You just need them to exist and work correctly, which redux-observable's typings would build on top of. the ones in flow-typed probably will work fine, but I was just warning that I have not tested them and so they could have holes or incorrect types for some things because rxjs is a large project and full of complex type scenarios.

[steida]

@jayphelps rxjs flow types works well, I am using it

// custom epic type
https://github.com/este/este/blob/a2d28238a1ba34c364343b4779d4a5e818908d31/types/index.js#L105

// type refinements
https://github.com/este/este/blob/a2d28238a1ba34c364343b4779d4a5e818908d31/lib/users/epics.js#L21

[rafaelkallis]

@steida I would be willing to help. Currently working on a rxjs based framework that extends the Observable just like ActionsObservable does and I'm using flow. Shouldn't be hard, given we already have the typescript typings. I also do suggest to make the flow typings a 1 to 1 replica of the typescript typings. I don't see any syntax on the redux-observable TS typings that can't be ported to flow typings.

EDIT: reference to TS typings: https://github.com/redux-observable/redux-observable/blob/6384c9f22df10621127dbf7002023faa0935573c/index.d.ts

[jayphelps]

Our typings are likely about to change in #250 to better refine the dependency injection type.

[steida]

@jayphelps I believe DI should include getState as well, all in one argument. I had to workaround current approach, and it works perfectly. https://github.com/este/este/blob/a2d28238a1ba34c364343b4779d4a5e818908d31/lib/root-epic.js#L16

[jayphelps]

@steida can you clarify what you mean? the store and the DI are different arguments, intentionally. I don't see that likely to change.

[steida]

Nothing more that's it's just practical. Look https://github.com/este/este/blob/a2d28238a1ba34c364343b4779d4a5e818908d31/lib/users/epics.js#L17

I can add getState, whatever. It's typed. I don't know why getState and other dependencies should be passed as the third argument.

[jayphelps]

@steida if you have a solid proposal, feel free to create a separate issue ticket RFC around it.

[steida]

Just create root epic and inject whatever in. It's more design pattern than lib feature. That's what I am using.

// @flow
import 'rxjs';
import type { Action, Dependencies, State } from '../types';
import type { Observable } from 'rxjs';
import { combineEpics } from 'redux-observable';
import { values } from 'ramda';

import * as usersEpics from './users/epics';

const importedEpics = {
  ...usersEpics,
};

const epics = values(importedEpics).filter(item => typeof item === 'function');

const rootEpic = (
  action$: Observable<Action>,
  { getState }: { getState: () => State },
  dependencies: Dependencies
) => combineEpics(...epics)(action$, { ...dependencies, getState });

export default rootEpic;

[rafaelkallis]

@steida I'm posting this here since there's no open issue yet, but it's not the right place to discuss.

Am I missing something or isn't getState already included, independent from DI?

Reference:

createEpicMiddleware.js

const output$ = ('dependencies' in options)
  ? epic(action$, store, options.dependencies)
  : epic(action$, store);

---

index.d.ts

export declare interface Epic<T, S> {
  (action$: ActionsObservable<T>, store: MiddlewareAPI<S>): Observable<T>;
}

where store: MiddlewareAPI<S> has getState.