Just to make this more clear: The poll is effectively about introducing a breaking change (existing custom components don’t work without manual translation to middleware) with Flow 7 by fully removing the Component layer, or if we should avoid this breakiness by all means (keep the code in for another major version and/or spend time building a b/c wrapper layer).
Alexander created a concept of http components as middleware. Main issue is the chain. Middleware does not have a chain (pre, process, post) as we do with http components. Middleware onle have positions. Correct me if wrong @aberl
It can live in a separate package, as a middleware, supporting the components. And thus, the focus of 7.0 will be to remove the deprecated Component stuff and bring in middleware as the main functionality.
Didn’t we agree to keep an optional b/c layer for 7.0+ (potentially in a separate package).
Main issue is the chain. Middleware does not have a chain (pre, process, post) as we do with http components.
Yes. The code I have to wrap a component in a middleware works well for the pre and post chains with distinct wrappers. But there is still the unsolved issue of wrapping a “process” component correctly, which seems to be not quite as easy. So the question is: Is that really worth the effort?
As Soren suggested, maybe can we extract the component chain into an own package that we provide as a middleware (6.3 ComponentChainMiddleware), but keeping the ComponentChainMiddleware is only a weak b/c layer, because no component will be able to act before(pre)/after(post) the place where the ComponentChainMiddleware is inserted into the middleware chain. So it would need to wrap the middleware chain. But that is not working well with “process” components and would dictate us to keep creating a blank “Http Response” early just to pass it along through the incoming components. Which was the reason why it is currently at the “end” of the middleware chain in the first place.
Also any third-party componentst that are currently registered at a specific position (e.g. “after sessionCookie”, “before setHeaders”), which are arguably nearly all, would break with that anyway.
So how should we deal properly with the upcoming breakyness, or should we just accept it?
Maybe the poll with a yes/no/neither option was too simplistic to capture the decision we actually need to make?
I wouldn’t be too happy with breaking a lot of packages again in 7.0 as we did with the whole Request Response PSR stuff in 6.0 which caused lot of work during upgrades. And for maintainers to work on more mayor versions since then to support all active Neos versions. I remember several packages that were marked compatible but were actually broken for one or the other Flow version.
I assume we have less components in the wild than packages that work with requests. But we need a smoother way this time to allow upgrades with less hassle.
Flow is moving fast currently We are implementing things we have had in the issue and PR queue for a while. And with super focus on changelog and documentation of changes, to help.
Please describe the needs more in details - let’s get the needs open, so we can aim at pushing that along with our changes, both now and in the future
I’m more fearful of new major versions, which lead to less maintenance of older versions. I also don’t think we will break too many community plugins. Only few projects I know have components outside of the Neos/Flowpack core packages.
I think a good upgrade documentation at least on docs.neos.io with example links / links to the upgraded packages. I also assume that there won’t be any migration script possible.
Again I compare to the PSR-7 change. We had many people in Slack quite lost on how to replace their code. I myself struggled in some places.
It would also be interesting if a package can be made compatible with Flow 6+7 at the same time. I was able to do that in some cases last time which helped a lot.
Thanks for all the effort and thought you guys put into this topic!
That’s a good idea, and probably the collection in the other thread we have will be a good start for such a documentation.
I also assume that there won’t be any migration script possible.
Yep, very unlikely we can build a migration script that translates those things automatically unfortunately (anyone willing to attempt that is highly welcome :)) - but once you know what from the components concept translates to what in the middlewares, it’s relatively straightforward (e.g. $componentContext->replaceHttpResponse($response); + $componentContext->setParameter(ComponentChain::class, 'cancel', true); = return $response;).
The hardest change is likely finding the “correct” position in the new middleware chain. Since the separation of the three chains (pre/process/post) is gone, you might need to put your “post” component somewhere at the start of the middleware chain to make it work as expected.
Again I compare to the PSR-7 change. We had many people in Slack quite lost on how to replace their code. I myself struggled in some places.
I totally understand that. And we could maybe have done better with that change, if we would have had more time and maybe a few more people help with playing around with the change early to collect the migration/maintenance issues that needed to be solved. Effectively it was mostly a two-man effort and we needed to push through this change to get it done at all, by the sheer amount of code that needed to change and was hard to review.
See also Flow PSR-7 change in master, we need your help!
+1 for merging the new middlewares asap. We already decided that we want to go this route IIRC.
As for b/c I think…
It’s inevitable to have proper upgrade docs (and it should also be explained in the Release-Notes & -Article)
I still hope that we can have a b/c package that will cover most of the cases (e.g. we could even interpret configuration options like before "routing" and invoke the corresponding component at the right point in time)
If the above is not possible (and for exotic cases that can’t be covered) it would be cool to have a code migration that at least detects those and outputs a helpful warning message
We are implementing things we have had in the issue and PR queue for a while. And with super focus on changelog and documentation of changes, to help.