-
Notifications
You must be signed in to change notification settings - Fork 30
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
0.3.0 - Export drivers to userland #28
Conversation
cfd9344
to
91fee30
Compare
Did you think about my idea of scoping the drivers under const cycleMiddleware = createCycleMiddleware();
...
ACTION: cycleMiddleware.actionDriver So that, in the end,
|
@goshakkk ok but what would you pass it to |
@lmatteis functions can have properties in js 😈 function createCycleMiddleware() {
const middleware = () => { ... };
middleware.actionDriver = ...;
return middleware;
}
const cycleMiddleware = createCycleMiddleware();
// cycleMiddleware is a fn
cycleMiddleware.actionDriver
// but it also has other fields There's nothing dirty about doing it like that. Redux-saga does something similar as well: https://github.com/redux-saga/redux-saga#mainjs |
Hrm not really happy about func props. You can't destructor them. I like the idea of having the drivers depend on the middleware though. |
Fwiw, you can: function a() {}
a.b = 5;
const { b } = a;
console.log(b) ;
// prints 5 |
91fee30
to
038f57a
Compare
@goshakkk ok makes sense. made changes. one thing is that i'm still exposing factories ( cycleMiddleware.makeStateDriver = () => {
const isSame = {};
const getCurrent = store.getState;
return function stateDriver() { Where would |
@lmatteis I think function createCycleMiddleware() {
let store;
function makeStateDriver() { ... }
const middleware = () => { ... };
middleware.stateDriver = makeStateDriver();
return middleware;
} Alternatively, we might not even need the factory functions at all, just assign the driver instances directly: function createCycleMiddleware() {
let store;
const middleware = () => { ... };
middleware.stateDriver = () => {
const getCurrent = store.getState;
return xs.create...;
};
return middleware;
} |
@goshakkk can we rely on that though? The driver will be executed by Cycle.js, hence |
@goshakkk i added a |
This PR should probably update the code in nevermind I can use npm local dependencies: |
e14dec0
to
73a997d
Compare
Another small comment (sorry for the spam): makeStateDriver() needs to be called after run, otherwise store.getState is undefined. Any ideas about this? |
@lmatteis just move that line to be inside |
CHANGELOG.md
Outdated
# 1.0.0 - 2017-02-12 | ||
|
||
**BREAKING CHANGES** | ||
- `createCycleMiddleware()` no longer takes any arguments. Instead you need to call `Cycle.run` yourself passing it your `main` function and `drivers` explicitly: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it also worth mentioning here and in the readme the need to [npm i -s/yarn add] xstream-run
?
73a997d
to
fd60a06
Compare
fd60a06
to
c25dbe0
Compare
Ok this might be ready to merge. Will wait for the green light from you guys |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. Can you tweak the readme with xstream-run install as well?
Another thing I am not sure about is — are we ready for 1.0? Or maybe should we still stay in the 0.x area?
README.md
Outdated
|
||
```js | ||
import { run } from '@cycle/xstream-run'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the readme mention the need to install it as well?
Well it's a breaking change no? So we need to bump up the first number. 0.3 would mean new features and no breaking changes. |
@lmatteis semver is pretty lax with 0.x's. 0.x means that a project is not yet ready for 1.0, but breaking changes can nevertheless naturally occur — because everything leading up to 1.0 is, in some way, "discovery" of the API, and use cases, and the bugs, and so on; v1.0 signifies the first "stable" / "reliable" version. So it's perfectly fine to make breaking changes and do a 0.3, 0.4, etc. while we're making and testing decisions. I'd cut 1.0 when we have more people using redux-cycles in production and sharing their feedback, so we will be in position to say 1.0 is truly battle-tested. More on semver: http://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase this obviously should be taken as a broad guideline, rather than a strict rule, but I do think this makes sense. |
Right but most users that do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
Jeez I didn't know there was so much disagreement with semver: dominictarr/semver-ftw#2 (comment) |
Hold on, will npm not update ^0.2.3 to 0.3.0? I can't find the right docs, but if EDIT: yup i tested it so npm is smart enough to interpret the leading 0. Ok se we can go with 0.3.0 |
c25dbe0
to
577f6b2
Compare
Ok I think I took care of all comments. Waiting for your thumbsup @goshakkk |
577f6b2
to
38e5eb5
Compare
@@ -22,7 +22,7 @@ | |||
"react-router": "^2.6.1", | |||
"react-router-redux": "^4.0.5", | |||
"redux": "^3.5.2", | |||
"redux-cycles": "0.2.3", | |||
"redux-cycles": "file:../", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hehe, nice one 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it
I've separated the two things into separate PRs. This only takes care of putting run in userland without Unified support.