-
-
Notifications
You must be signed in to change notification settings - Fork 101
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
Register components lazily #136
Conversation
Thanks! |
I believe this patch may have caused issues for me - my app now fails to run
The cause of the error is Blade UI kit trying to find trying to find an icon, but because this change appears to interact with the Blade compiler I suspect it is the culprit. I'm having a little trouble narrowing down why, as so far it's only reproducible on my servers. Things of note:
|
I believe I've narrowed this down to the view composer replacement. When I revert that back to using the facade the problem goes away. Would reverting the view composer back affect the original problem this PR set out to solve? |
Hey @dwightwatson I'm so sorry it caused troubles on your end! Normally, this change should not have affected anyone because the façade calls are doing the exact same thing as in the lazy registrations. It's just that the registrations now only happen right before the objects are requested through the container.
They don't have to be static; it's just a slight performance optimization as the
The
Yes, unfortunately it would. Does this error messages arise when the |
What's super odd about this is that it sounds awfully similar to a bug I experienced earlier inside Laravel, though it was thought to have been solved. However others have since popped up having the same problem. The tl;dr being that using You mention that the facade does the exact same thing but clearly that isn't the case. Not really sure what the solution is here, I've had to lock to the previous version but would prefer to find a resolution. |
Apologies - forgot to reply to your last bit. The server in question is Heroku so actually getting the logs out of it when this occurs is pretty impossible. All I've got is the stack trace out of Sentry.
I'll try to keep playing around to see if I can find a better way. |
Hey man! I haven't forgotten about this. I'll try taking a look myself tomorrow. Have you been able to find anything useful in the meantime? Thanks! |
All good - no, I haven't come up with anything of substance. And because the issue is only presenting itself on Heroku dynos the feedback loop doesn't make it easy. I think there's just some gnarly weird bug under the hood that has some relationship between the I wrote a note about this on the Otherwise I think I may drop using the |
Hi! 👋
I was trying to test a contact form page until a pesky problem reared its head:
Further investigation lead me to laravel-honeypot as the package seems to register its services eagerly. I do recognize not everyone is making use of application siloing (registering only the necessary service providers at the last possible moment), but this change would also benefit every application by becoming a lazy service registrar.
callAfterResolving
is a method that has been in the framework since v5.6, so it won't break BC. (Please see this article for more context).I have also removed the
$this
return in the last method in the chain of calls, as it was unused.Thank you! 🙏