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

Introduce new middleware API #29

Merged
merged 7 commits into from
May 21, 2018
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions lib/Store.lua
Original file line number Diff line number Diff line change
Expand Up @@ -48,12 +48,18 @@ function Store.new(reducer, initialState, middlewares)
table.insert(self._connections, connection)

if middlewares then
local dispatch = Store.dispatch
local unboundDispatch = self.dispatch
local dispatch = function(...)
return unboundDispatch(self, ...)
end

for _, middleware in ipairs(middlewares) do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to do anything with #28 to make middleware ordering line up with Redux?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be the time to do it, but I'm unsure if we want to change the order. Because the middleware call sequence depends entirely on what the middleware actually do, I don't think either behavior is particularly intuitive...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're not very intuitive, but at the same time I'm not sure there's a nicer way of specifying middleware order besides an array >.<

I think if we're going to stick to an array for middlewares then invoking them from the front of the list forward makes the most sense, but that's just me

Copy link
Contributor

@ZoteTheMighty ZoteTheMighty May 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it's not intuitive either way.

I think the best approach is to probably document the way that the middleware is applied, because if you ever write any middleware there's a good chance you'll need to know one way or another. As long as the info is easy to find that should be enough.

Also, this doesn't necessarily need to be added in this PR.

dispatch = middleware(dispatch)
dispatch = middleware(dispatch, self)
end

self.dispatch = dispatch
self.dispatch = function(self, ...)
return dispatch(...)
end
end

return self
Expand Down
6 changes: 3 additions & 3 deletions lib/loggerMiddleware.lua
Original file line number Diff line number Diff line change
Expand Up @@ -39,9 +39,9 @@ local loggerMiddleware = {
outputFunction = print,
}

function loggerMiddleware.middleware(next)
return function(store, action)
local result = next(store, action)
function loggerMiddleware.middleware(nextDispatch, store)
return function(action)
local result = nextDispatch(action)

loggerMiddleware.outputFunction(("Action dispatched: %s\nState changed to: %s"):format(
prettyPrint(action),
Expand Down
6 changes: 3 additions & 3 deletions lib/thunkMiddleware.lua
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,12 @@
This middleware consumes the function; middleware further down the chain
will not receive it.
]]
local function thunkMiddleware(next)
return function(store, action)
local function thunkMiddleware(nextDispatch, store)
return function(action)
if typeof(action) == "function" then
return action(store)
else
return next(store, action)
return nextDispatch(action)
end
end
end
Expand Down