after #92 is implemented

Is this an expected behavior? I would expect that after ejecting reducer (in other words, once the component which contains withReducers() is unmounted), reducer data from store should be removed, right? And if not so, there should be at least option to do so.
Because otherwise, if there is an middleware which adds items on fired action, it will created duplicated data.

Thanks in advance.

Provide READMEs to every package.

The current version is incompatible with react-redux v6. Because of HOC withInjectorContext, where the store is passed down the props.

Provider is not something we depend on for the injection mechanism anymore (because we use the React Redux context instead)

because the Provider is tied to namespacing only, it should be moved to its own package

The Redux implementation is too opinionated, because it assumes that the state structure is always static – if we inject/eject reducers dynamically, state can be lost. Furthermore, combineReducers does not allow any other keys (they are ignored), which is especially painful for rehydration of state when the appropriate reducers are not mounted yet (state gets lost)

Currently, whenever an action goes through a namespaced middleware, it is immediately associated with that namespace, which doesn't make sense. Only actions dispatched within the middleware should do so.

The fix is either to somehow wrap dispatch to assoc the action, or expose attachNamespace more and make it more aggressive.

it also shouldn't store keys when using an array. current implementation makes it way too easy to inject an epic/middleware twice

• Add support for variadic action creators (makeBinaryActionCreator)
• Add makeMiddleware and composeMiddleware to middleware (makeMiddleware will not be added because it is too specific, perhaps in another issue)
• Add scopeReducer to reducers (not added, but no longer necessary due to #155)
• Add useNamespacedSelector (optional feature arg) to @redux-tools/namespaces-react

Instead of using feature = "namespaces" everywhere, it should at least be a constant (or make sure to only default possible user entry points).

possibly even arrays of action types. this should be possible:

makeReducer([
  [ActionType, reducer],
  [[ActionTypeOne, ActionTypeTwo], reducer],
  [isSomeActionType, reducer]
])

In order to improve DX, the code should look like e.g.:

const withMiddleware = makeInjector(
  'Middleware',
  prop('injectMiddleware'),
  prop('ejectMiddleware')
);

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Hey, it seems that with usage of withReducers(), the initial state passed during store initialization is ignored.

Typical use case is for reason of local storage to set reducer state:

Instead, I should be doing something like this:

Ideally, there could be api to provide initial state together withReducers() HOC?

Thanks in advance.

use of makeActionTypes is discouraged because of no IDE autocompletion. can this be solved by TS typings in Vanilla JS apps?

if not, makeActionTypes should be deprecated imo

After injecting either a reducer or a middleware redux-devtools-extension stops the logging of actions.
Fix is to set options to devtools like that:

	const composeEnhancers = composeWithDevTools({
		// NOTE: if not set the extension breaks after injecting reducers
		latency: 0,
		// NOTE: if `true` extension breaks after injecting reducers
		shouldHotReload: false,
	});

I think it would be useful to warn our precious users about that.

https://bundlephobia.com/result?p=@redux-tools/[email protected] shows a warning about missing deps

i think we should help the existing tools by specifying the transitive peerDependencies manually in all exported packages

we should also check the peerDependencies of all other packages to see if there are any discrepancies

• namespaces-react should contain NamespaceProvider, useNamespace, namespacedConnect
• makeReducer should be moved to reducers
• getStateByAction and getStateByNamespace should be moved to namespaces

Mainly wrt. async mode.

Suppose a component's constructor was called, but the component isn't mounted after all (possible situation in async mode). It is not yet known if componentWillUnmount will fire. This would make it impossible to reliably eject injectables without any leaks.

Injecting in componentDidMount has a single disadvantage: inner components' componentDidMount methods are fired first, so a common pattern of e.g. fetching data would not work, because the reducer/epic/middleware would not have been mounted yet.

Microsoft's solution uses state to delay rendering of inner components, which would also work in our case.

There are a couple of possible problems:

1. Using refs from a parent component can break, but this isn't a likely scenario, because refs are rarely used to access containers. (If we were to use refs in parent's componentDidMount, we would've expected the child component to be mounted, but the mount is actually delayed.)
2. Performance, white flashes, etc., especially with regards to SSR and hydration:
   1. static render
   2. first React render
   3. statically rendered content is removed (due to change in state)
   4. second React render
   5. content is rendered

In order to have preloading of content in SSR possible at all, the injectables have to be defined statically and mounted in e.g. async getInitialProps. Because of our entry system, we do not have to worry about duplicates. When rendering on the client, injectable IDs have to be passed to from the server (somehow) and then injected BEFORE rendering the React application. The injector state (whether componentDidMount should be delayed) should thus depend on whether the injectable is already injected (resulting in no flashes).

It should also be noted that regardless of async mode behaviour, this approach is cleaner, because no side effects happen in the constructor (and everything can be rewritten to use hooks... perhaps). We'll also be able to get rid of all the versions (finally).

https://github.com/lundegaard/redux-tools/blob/master/packages/middleware/src/makeEnhancer.js#L12

This memoization is useless, it needs to be hoisted up so it only runs once

they should be composed with all the reducers

especially in middlewares

to avoid "value is not a function" errors, which are undecipherable

If I have a middleware which turns my dispatched actions into promises, I want to be able to get that promise back dispatching action eg.:
const promise = dispatch(action())
but because of makeEnhancer from @redux-tools/middleware, it always returns undefined instead of promise.

this is useful for affecting all widgets from a single widget (must be mentioned in the docs!)

attachNamespace(null, action) might work, but i think there should be an explicit function for this.

we should ensure that any mechanism where the namespace can be overridden is using defaultNamespace (notably actions dispatched via namespacedConnect, injected middleware, epics)

defaultNamespace should include tests checking that if an action has namespace: null, it won't be changed

is namespace: null sufficient? perhaps a constant would be better.

proposed names for the function:

• unsetNamespace
• removeNamespace
• dissocNamespace
• detachNamespace

the issue with these names is that the behaviour is not reflected in the name. we are not unsetting a present namespace. we are preventing a namespace to be set automatically.

maybe something like

• globalizeAction
• preventNamespace

i'm inclining towards preventNamespace having an explicit constant (NAMESPACE_PREVENTED)

makeActionTypes, options for decorators

We call middleware(reduxAPI)(next) per each action. This is wrong, each middleware should only be initialized once and then we should only call something(action)

Would be possible to have both words of the title of the library "Redux Tools" on the same line?
I think it would be nicer on the web.
If you provide a source file I can change it myself.

Also, the transparent background would be more flexible.

Instead, another option could be added: requireNamespace, which would trigger the same warning/error if a namespace is not received.

currently, its way too easy to do const updateSomething = makeSimpleActionCreator(UPDATE_SOMETHING) and dispatch updateSomething() accidentally.

this will just break stuff. the user should be notified with the following message

You did not pass an argument to an action creator created by `"makeSimpleActionCreator(${type})"`. Did you mean to use `"makeConstantActionCreator(${type})"`?

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

we should compose the reducers somehow

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

https://github.com/lundegaard/redux-tools/blob/master/packages/react/src/index.js

in EJECTED, payload is null if the injectable is a function. we should pass function.name instead in both INJECTED and EJECTED

redux-tools might have problems wrt. building application bundles – if a redux-tools package requires e.g. ^0.26.1 version of ramda, and an application has 0.25.0 as a dependency, two copies of ramda will be included in the final bundle

The actual state of packages is just proof of concept that rollup can be used within monorepo.

Please provide real packages and remove old ones.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Copy pasted from an internal project:

{ 
  someModule: {
    common: {}, // App bound
    someView: {}, // View bound
  }
}

but when you navigate from SomeView to OtherView, you would get

{ 
  someModule: {
    common: {}, // App bound - preserved across navigation
    otherView: {}, // View bound - fresh initialized
    // someView gets dropped
  }
}

Of course the same can be achieved by using prefixed names like someModuleCommon or someModuleSomeView, but the nested variant looks nicer.😃

Momentarily there is just "^5.1.0". We now support v6 as in #17.