karlpurk / redux-decorators Goto Github PK

May I know is Action / Reducer are always registered globally?

In the Plnkr example, app/action-reducers.ts registered some actions. If I have a large application, looks like I have to be careful with naming my action name, make sure there is no duplication.

As it is right now the only way to use the action is by

class MyReducers {
    @Reducer() add(state): { return { count: state.count + 1; } }
}

An idea that i have on how to make this better is doing something like:

class MyReducers {
    @Reducer() add(state, action): { console.log(action.payload) }
}

What do you think?

Currently @Store and @State just push new changes into a property on the target class.

We should investigate how an implementation using RxJS observables could work.

Would it require a new decorator or can we extend an existing one?

Are these mutually exclusive or should we allow users to mix observables with normal properties?

I'm unable to add @State() todos:Todo[] = []; to the @Store as State is not available on index.d.ts.

The PR below adds this to index.d.ts to make State available in TS.
export function State(...name: string[]): Function;

See PR #12

Hi,

I'm really liking the idea of these decorators. But I'm curious it it would be possible to use multiple stores? I.e. in a larger app, one to hold the state for say the breadcrumbs, and another to hold the state of the page itself. How could I go about achieving this?

Thanks

Inital Redux action type is never being caught and initializing state. I noticed inital action type from Redux was always coming in @@INIT instead of @@redux/INIT. I changed the check to test for the regex expression instead /@@.*init/ig which fixed the issue. This catches either @@redux/INIT or @@INIT.

See PR #12

I think action reducers should be passed the value that they operate on, rather than the full state tree. So instead of:

class MyReducers {
    add(state): { return { count: state.count + 1; } 
}

Instead we should be able to write something like this:

class MyReducers {
    add(count = 0): { return count + 1; }
}

The question is how do we achieve this with decorators? Do we assume that a class of action reducers all work on the same state slice, like this:

@Reducer({slice: 'count', actions: ['add', 'remove']})
class MyReducers {
    add(count = 0): { return count + 1; }
}

Or do we implement this on a per-method basis, like this:

class MyReducers {
    @Reducer('count') add(count = 0): { return count + 1; }
}

Thoughts?

Is there a was to subscribe to appState's state changes? The simple bindings for component properties is phenomenal, but my components and services need to run custom code on state change.
My proposed enhancement is for @Store to detect which stateProperties are functions and have them subscribe to appStore.

I wanted to check that there wasn't an easier existing method to subscribe to @Store and that the above proposed implementation was acceptable before I started working on an enhancement in my fork.

Thanks!

Now:

class MyReducers {
    @Reducer('add') add(state): { return { count: state.count + 1; } }
}

Enhanced:

class MyReducers {
    @Reducer() add(state): { return { count: state.count + 1; } }
}

Is this possible?

It did not work when using it in combination with webpack. I had to go to the package.json and change the following:

"main": "src/redux-decorators.js" to "main": "dist/redux-decorators.js"

After this Webpack was able to resolve the module no problem.

Redux Devtools Extension is fantastic for debugging Redux apps. Below is a PR that makes it work if it's available in the window. If it's not available, then nothing should change.

See PR #12

TSD to Typings which is recommended now by the TSD author.

DEPRECATED: TSD is deprecated, please use Typings and see this issue for more information.

See PR #12 for change

The more I look at the dual purpose of the @Reducer decorator the more I dislike it.

It doesn't make sense to have one decorator serve 2 purposes.

There are a few options here.

1. Introduce a new @RootReducer decorator and move the root reducer functionality to this new decorator.
2. Introduce a new @Action decorator and move the action reducer functionality to this new decorator.

Perhaps a combination of the two?

Thoughts welcome.