Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Factor out a `MutableState` interface from the store and provide an ImmutableJS implementation #242

Merged
merged 13 commits into from Feb 26, 2019

Conversation

@maier49
Copy link
Contributor

commented Feb 5, 2019

Type: feature

The following has been addressed in the PR:

Description:

Related to #48

This creates a MutableState interface that has the properties of State as well as the apply function. It then breaks out the parts of store that implemented the MutableState interface into a default implementation, and allows an alternative implementation to be passed in to the constructor.

Includes an implementation using ImmutableJS. So far testing the performance impact of using ImmutableJS has not shown significant differences but I have not thoroughly tested it.

@maier49 maier49 requested a review from matt-gadd Feb 6, 2019

@maier49

This comment has been minimized.

Copy link
Contributor Author

commented Feb 6, 2019

Looks like this version of immutable has different behavior in IE than other browsers so I'll have to sort that out

@maier49

This comment has been minimized.

Copy link
Contributor Author

commented Feb 12, 2019

Switched to using the latest fully fledged version of Immutable which doesn't suffer from the same issue.

@@ -52,6 +52,7 @@
"css-select-umd": "1.3.0-rc0",
"diff": "3.5.0",
"globalize": "1.4.0",
"immutable": "3.8.2",

This comment has been minimized.

Copy link
@agubler

agubler Feb 15, 2019

Member

Should we include immutable as a dependency, or make it a dev dependency and also an optional dependency?

This comment has been minimized.

Copy link
@maier49

maier49 Feb 26, 2019

Author Contributor

I made it an optional and dev dependency. In the code I just wrapped the require in a try. I'm assuming that we expect that module will fail if Immutable isn't installed, but I'm not sure how we want to handle that. I didn't see anywhere else we're using optional dependencies so let me know if that's the wrong approach.

This comment has been minimized.

Copy link
@agubler

agubler Feb 26, 2019

Member

Perhaps we should put something in the README to say that they would need to install immutable.... Or maybe having it as a dev isn't the end of the world... it's not going to affect anything unless they use it anyway.

This comment has been minimized.

Copy link
@maier49

maier49 Feb 26, 2019

Author Contributor

Your call. Since it should be left out if they're not using it I'd be fine with it being a dependency.

This comment has been minimized.

Copy link
@agubler

agubler Feb 26, 2019

Member

yeah let's put it in the deps again. sorry!

This comment has been minimized.

Copy link
@maier49

maier49 Feb 26, 2019

Author Contributor

No problem. Reverted

@maier49 maier49 force-pushed the maier49:48-patch-performance branch from daf0e8d to b0c7b23 Feb 26, 2019

maier49 added 2 commits Feb 26, 2019

@maier49 maier49 changed the title 48 patch performance Factor out a `MutableState` interface from the store and provide an ImmutableJS implementation Feb 26, 2019

maier49 added 3 commits Feb 26, 2019

#### ImmutableState

An implementation of the `MutableState` interface that leverages [Immutable](https://github.com/immutable-js/immutable-js) under the hood is provided as

This comment has been minimized.

Copy link
@agubler

agubler Feb 26, 2019

Member

Is this formatting a little off with line endings?

This comment has been minimized.

Copy link
@maier49

maier49 Feb 26, 2019

Author Contributor

I moved it to one line to avoid any issues.

@@ -62,12 +62,12 @@ describe('middleware - local storage', (suite) => {
it('should load from local storage', () => {
global.localStorage.setItem(LOCAL_STORAGE_TEST_ID, '[{"meta":{"path":"/counter"},"state":1}]');
load(LOCAL_STORAGE_TEST_ID, store);
assert.deepEqual((store as any)._state, { counter: 1 });
assert.deepEqual((store as any)._state._state, { counter: 1 });

This comment has been minimized.

Copy link
@agubler

agubler Feb 26, 2019

Member

A side effect of the impl is having state stored in a nested _state._state object. Do you think that it should probably be something like _adapter._state?

This comment has been minimized.

Copy link
@maier49

maier49 Feb 26, 2019

Author Contributor

_adapter seems reasonable to me. I've updated it

@maier49 maier49 merged commit 806114b into dojo:master Feb 26, 2019

2 of 4 checks passed

codecov/patch 96.94% of diff hit (target 97.34%)
Details
codecov/project 97.32% (-0.02%) compared to 451d2f5
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
licence/cla Contributor License Agreement is signed.
Details

@maier49 maier49 deleted the maier49:48-patch-performance branch Feb 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.