Hello there!

My name is Ana. I noted that you use the mutation testing tool StrykerJS in the project.
I am a postdoctoral researcher at the University of Seville (Spain), and my colleagues and I are studying how mutation testing tools are used in practice. With this aim in mind, we have analysed over 3,500 public GitHub repositories using mutation testing tools, including yours! This work has recently been published in a journal paper available at https://link.springer.com/content/pdf/10.1007/s10664-022-10177-8.pdf.

To complete this study, we are asking for your help to understand better how mutation testing is used in practice, please! We would be extremely grateful if you could contribute to this study by answering a brief survey of 21 simple questions (no more than 6 minutes). This is the link to the questionnaire https://forms.gle/FvXNrimWAsJYC1zB9.

We apologize if you have already received message multiple times or if you have already had the opportunity to complete the survey. If you have already shared your feedback, we want to convey our appreciation, kindly disregard this message, and please accept our apologies for any inconvenience.

Drop me an e-mail if you have any questions or comments ([email protected]). Thank you very much in advance!!

Now we are logging in the console all activity related with events, effects and coeffects.

Maybe would be nice to implement an integration with Redux dev tools that might enable us to log this data in this tool if installed (and behave as we do now as a fallback).

This also will enable us to create effects with an specific integration with this extension. I.e. if we have an effect for mutate the reffects-store state, we could have an historic of the mutations againts it and know the current values of properties in this state, that will provide us with usefull data in developement.

This is the API reference of the devtools:
https://github.com/zalmoxisus/redux-devtools-extension/tree/master/docs/API

Also, we have already done some POC to know if it is possible.

We're currently using microbundle to generate all our distribution files. Now we need more customization over sourcemaps and minification options. We should consider using another library to generate those files: rollup could be a nice candidate. (It's actually the library where microbundle is running on top of)

• Microbundle: https://github.com/developit/microbundle
• Rollup: https://rollupjs.org/guide/en/

Bug report

Describe the bug

Using the queryParams coeffect, when deconstructing the values for the event handler, not present values are set to null by default in the coeffect. Since they are null, you can not give them a default value with the syntax {key = 1}.
Easiest solution I can think of is changing the default value to undefined (or avoid adding the value to queryParams result if the value is not present), but let me know if you think there is a better way :)

To Reproduce

1. Create an effect handler like this

registerEventHandler(
    'EVENT_HANDLER',
    (
      {
        queryParams: { foo = 'hello' },
      }
    ) => {
      return state.set({
        something: {
          foo
        },
      });
    },
    [
      queryParams.get(['foo']),
    ]
  );

2. Trigger the effect on a page with url /hello (no foo query param added)

Expected behavior

Application state should be set with {something: { foo: 'hello' }}, but it has {something: { foo: null }}

Additional context

This is the line that should be changed https://github.com/trovit/reffects/blob/master/packages/batteries/src/queryParams/queryParams.js#L22

Currently injectedProps only support an object of functions or static props we want to inject to the subscribed component. We found some cases where we needed to access to the current state to decide which action to take or pass some computed state to the dispatched event payload.

What we have:

subscribe(Component, null, {
    onClick() {
        // dispatch something
    },
});

Example of what we suggest:
In the following case we can cover conditions that otherwise would be done directly in the UI like deciding a behaviour based on a feature flag.

subscribe(Component, null, (state) => {
    return {
        onClick() {
            if (getFeatureSelector(state, 'FF')) {
                // dispatch A
            } else {
                // dispatch B    
            }
        },
    }
});

Another example:
We all know that, in any event, state is accessible through coeffects, but we could dispatch events with a payload using data computed from the state selectors.

subscribe(Component, null, (state) => {
    return {
        onClick() {
            const data = someSelector(state);
            dispatch({id: 'EVENT_ID', payload: data});
        },
    }
});

More

The intention of this is not to start putting logic in these injected props but to gain flexibility to move some logic from the UI to these functions, if convenient.
Also, for backwards compatibility injectedProps could be expected both as a callback and an object.

Feature request

Is your feature request related to a problem? Please describe.
Nowadays when we want to ensure the order of execution of certain effects we can't do it unless we use auxiliary event handlers to encapsulate them and then use {{dispatchMany}} (which ensure us the order of dispatch).

For example, maybe I want to mutate state, but at the same time do a side effect (dispatching another event) which relies that this state mutation happened before of this effect handler execution.

Describe the solution you'd like
I propose to have a reverse compatible implementation which supports returning an array in an event handler being possible to do:

return [
    state.set ({all: newTodos}),
    effects.dispatch ("anEvent"),
]

Instead of:

return {
    ... state.set ({all: newAll}),
    ... effects.dispatch ("anEvent"),
}

The first one will ensure you the effect handler execution order in the sequence you declare the effects.

Also, you avoid using spread operator.

Describe alternatives you've considered
You also can pass to the state effect and the dispatched event in the payload the same value and ignore the execution order in some scenarios (is the solution I've use).

Today we're using two repositories to work with reffects (reffects and reffects-store). Every time we have a change, we need to test not only the automated unit tests but also some manual checks that everything between libraries is working as expected (not always, but sometimes this is necessary). Also, when introducing a feature, sometimes we need to release both projects separately in different repositories.

I think it could be interesting to study the development of reffects & co. as a monorepository, to improve the development experience, improve the release process and have more close those two libraries (and other that could be related with reffects, like some predefined effects or coeffects).
Also, It's true that you can use reffects without the store, but this could not be a problem since once they are released, they can be imported as a separate different packages. So if you do not need reffects-store simply don't import it.

Resources:

• A project that can help us through this would be Lerna https://github.com/lerna/lerna
• Some libraries using these approach are:
• https://github.com/zerobias/effector (using lerna)
• https://github.com/facebook/react (not using lerna)
• https://github.com/developit/unistore (not using lerna)

As a final thought, this would ease us to have an examples directory or a playground that could use the current development state of both reffects and reffects-store to play with it when necessary.