-
-
Notifications
You must be signed in to change notification settings - Fork 834
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
Global access to the request object #2307
Comments
Hi, and thanks for your suggestion! 😃 Sorry, this is one of the cases where I really want to veto. I've taken great care to ensure that Flarum can easily be used with modern approaches like application servers (ReactPHP, PHP-PM, ...). This requires a mental shift from the good old days when everything was always "shared-nothing": global state was global, but only for the current request. No leaks, no worries. I want to keep the container and application classes free of per-request objects. They should only deal with truly application-wide state, whether the PHP process only handles one request or multiple. There is one object tree that can be long-living, and then there are object trees for each request. In the traditional world, there will be no difference between them, but once you run with a PHP application server, there is. Laravel does this, true, and I don't particularly like that. 😉 The downsides can be circumvented, alright, but you have to be aware of them. Just look at some of the dark magic that the Swoole adapter for Laravel has to do. Having this clean separation can sometimes make specific things a bit more complicated (though not impossible, in my experience), but has the benefit of being compatible with the different ways to run PHP applications - by design. I believe we still have a few weaknesses in this regard, too, e.g. translator and possibly auth stuff, but I'd rather see those fixed than introducing more of them. I hope this is understandable. 😉 |
Feature Request
I think it would be handy for extensions developers to provide something like
app('request')
to be able to access the current request object from anywhere in the code.I agree that it may not be a good practice to resolve that object this way, but in some very specific cases this can be very useful. Also Laravel has done this so I think it is safe to do it for Flarum as well.
As I briefly mentioned in #2306, this could easily be achieved with a Provider that registers a singleton and a Middleware that assigns an instance to that singleton.
The text was updated successfully, but these errors were encountered: