V2 Middleware API #703
Comments
|
How about a Redux-inspired middleware? Add a import logger from "@hyperapp/logger"
app({
// ...
middleware: [logger]
// ...
})For the implementation of a middleware you could have something like: // next would be the dispatch function here
const logger = next => action => {
console.log('before state: ', next(state => state))
console.log('action: ', action)
const result = next(action)
console.log('next state: ', result)
return result
}Each |
app({
// Your configuration here
}).hook(logger, otherMiddleware); |
|
Is internal |
|
@sergey-shpak No, it isn't. Middleware will let you "hook" into the internal dispatch mechanism, that's all for now. |
|
A simpler alternative (from Hyperapp's implementation perspective) would be to write middleware as a higher-order const logger = dispatch => action => {
console.log('before state: ', dispatch(state => state))
console.log('action: ', action)
const result = dispatch(action)
console.log('next state: ', result)
return result
}
app({
middleware: logger
})Essentially your middleware is passed the original The main downside to this approach is that using multiple middlewares will require the use of a |
|
@okwolf What is |
A typo. 😒 See the correction above. |
|
An advantage/disadvantage of the higher-order |
|
@okwolf If so it would be hard to implement things like |
|
@okwolf A crazy strategy could be to publish our own modified apps that support different functionalities. The main problem with that is combinability, like if there is a withApp1 and withApp2, how to use both? |
You mean like how Elm supports browser navigation by publishing their own |
|
If middlewares are an High Order Or I am missing something ? |
I agree, that's one of elm's sharp edges. If there's a middleware system built into hyperapp, I would prefer to just pass an array of middlewares to the |
|
I think the only real advantage to wrapping the entire |
|
@jorgebucaran what's the planned middleware API at this point? |
|
@okwolf I still don't know. 😥 |
|
🙏 |
|
At this point should we even try and include middleware in the first release, or add it later? |
|
@okwolf I don't think so. |
|
@jorgebucaran think of the devtools! |
|
@okwolf Maybe something like this could work. What do you think? import { app } from "hyperapp"
const actionMiddleware = action => action
app(actionMiddleware)({
// The usual propspects.
})e.g. app(action => console.log(action.name))({
// The usual props.
})
// or also
app(action => (state, data) => newState)({
// The usual props.
}) |
|
@jorgebucaran would this example prevent the original action from being dispatched? app(action => console.log(action.name))({
// The usual props.
})If not, would this run before or after the state was updated? Wouldn't the real logger be more like this? app(action => (state, data) => {
console.log('before state: ', state)
console.log('action: ', action)
const result = action(state, data)
console.log('next state: ', result)
return result
})({
// The usual props.
})Depending on how we handle actions that aren't functions. |
|
@okwolf The return value must be a function, so we could check if it's indeed a function and if it is not, return the original action, otherwise let you replace the action. Or, just force you to return the action. And it would run before the action is called. Your proposed logger would only work for actions that return a new state, not those that return effects. |
|
@okwolf Ah, that is unless we invoke the middleware callback for every state change with the name of the action instead. 👍 But then why would you use middleware for other than logging? We need to answer that question in order to move forward with this issue. |
|
What about redux dev tools? Logging is not the most effective way to debug for some people. Time travel is important. As well as seeing diffs, not just new state 🙏 Polluting the console can happen if a lot of actions are triggered and you are looking for specific logs that you have in your code. So in Vue the idea of plugins is widely used, would this be subscriptions for us or middleware? Just curious 😄 |
|
I can see how this could open somewhat of a Pandora's box if we're not careful. 📦 Middleware could be used to add support for features that go against the philosophy of 2.0, like dispatching I don't think there's really a huge practical difference between a higher-order action or |
|
Two other production use cases for middleware:
Technically you could use We need more voices to weigh in on this topic! |
That is the job of a subscription. I really didn't understand the downside you wrote below. 🙈 I am going to close here and create a new issue (soon / when I'm ready) to discuss the middleware API again, from scratch. The scope of the issue was too wide and while the discussion was fruitful, I want to narrow it down to the specific kind of middleware that I'd like to see in V2. The kind of middleware that I want to see is the least invasive kind, the one that allows you to build a logger or a time travel debugger, but not modify how dispatch works in order to, among other things, add Promise support to actions, etc. |
Then either I don't understand the philosophy behind subscriptions or we should consider changing their API. It was my impression that the
Do you have a proposal yet for how to have the former without the latter? 🤔 |
I understand how subscriptions work, as I've written a few already for testing in |
|
I don't understand what you mean by abuse. One of the strengths of a declarative subscription system is that subscriptions can be turned on and off as a function of the state, much in the same way you can create and destroy DOM elements using a VDOM. |
and others
A middleware API will allow you to easily create modules like a logger for Hyperapp 2.0.
Let's use this issue to discuss how middleware could look like in 2.0.
Please share your best ideas.
The text was updated successfully, but these errors were encountered: