Darkdawg started a new conversation+100 XP
2mos ago
Hey!
I created a SFC for a Flux:select, using the Modelable attribute. However, when triggering a save from the parent component the value isn't grabbed from the child. I'm using wire:model without any modifiers.
Changing to wire:model.live works, but I don't want the redundant requests.
This works with the old class based components, so I'm wondering if this is a bug?
Darkdawg wrote a comment+100 XP
3mos ago
Love Livewire!
I'm running Livewire in a somewhat weird way these days. I store the full page response as plain html pages, stripping out CSRF tokens and anything dynamic using middlewares and such. On page load I inject them again using fetch requests and cookies.
Livewire is still there, I just use the manual Livewire.start() approach to ensure CSRF tokens are injected before booting it. Works great, and I can now serve the whole app through a CDN like Cloudflare, giving me instant response times. Any Livewire update request just goes straight back to the server as usual. Just gotta make sure the cache gets busted on updates, but that's simple enough.
Darkdawg wrote a reply+100 XP
4mos ago
I think you're missing my point.
A page becomes dynamic (in the caching sense) only when the HTML output varies per user or per request. Livewire itself doesn't magically make a page dynamic - it's the session-bound CSRF token injected into the HTML that does. Is a page dynamic just because it has a <form>?
Yes, Livewire requires PHP to handle its update requests, but that happens after the page is loaded. My point is strictly about the initial HTML response. That response could theoretically be fully cacheable if it didn't include per-user data like the CSRF token. All subsequent Livewire requests would still hit Laravel normally.
My theory is that the CSRF token is unnecessary for public, non-auth pages, because there is nothing to protect against. Without the token the page can be fully cached, and you still get to keep all the wonderful things Livewire gives you. The SPA navigation and the server-driven reactive forms for example.
As far as I know, there's nothing a malicious site could achieve through a public Livewire component that it couldn't already do by just requesting the same public endpoint directly. Since there's no authenticated state involved, CSRF doesn't actually block any meaningful attack here.
I may be missing something about how Livewire internally depends on CSRF, so that's what I'm trying to understand better.
Darkdawg wrote a reply+100 XP
4mos ago
Sorry for resurrecting a 7-month-old thread, but I was hoping you or someone could clarify a few things.
I'm experimenting with Livewire components on public, non-auth pages (same HTML for all users). From what I understand, these routes don't really benefit much from CSRF protection, right? My impression is that CSRF is mainly meant to prevent unwanted actions on behalf of an authenticated user, so for pages that don't have any user-specific state or actions, I'm not sure what it would be protecting against.
My goal is to fully cache these pages as static .html. The problem is that Livewire injects a CSRF token at the end of the <body>, and because the token is session-specific, it breaks the cache. If I strip the token out of the cached page, Livewire stops working whenever it tries to make updates.
I'm fairly sure the CSRF token is unnecessary for completely public pages with no user-specific state - but I might be wrong. Would it be a bad idea to disable CSRF verification for these specific routes so that Livewire can work without injecting a per-user token?
Any insight would be appreciated!
Darkdawg wrote a reply+100 XP
5mos ago
Alright, I'm also using the ide-helper package, as well as the official Laravel IDE extension for VS Code (which does mention something about Livewire support in the works). It would be awesome if at the very least public & computed properties would show up.
I feel like sometimes when I watch Youtube tutorials/coding sessions the users get intellisense for their views as well, but it might just be AI code completions, I wish I knew.
I usually opt for the default naming convention myself (whatever comes from the Artisan create command). I didn't notice any difference with one or the other, though.
One recent (beta) extension/package I would definitely recommend looking into is the one Filip Ganyicz is working on. Check out Bond & Livewire SFC/Volt support extension, the latter switches between language mode (PHP/Blade) depending on where you click in a single file component. Last time I tried Volt it was pretty unusable in VS Code, because IDE support was terrible.
Darkdawg started a new conversation+100 XP
5mos ago
Looking for extensions/tips to improve my VS Code experience with Livewire 3/4 MFC/SFC.
I'm currently using the MFC/class based approach, but what bugs me the most is that my views have zero knowledge of my classes, so whenever I reference any variable all I get is (global variable) $category even if this is defined as public Category $category in the class.
Not sure if this is any better with the Volt/SFC, but from my brief testing it was the same.
Would PHPStorm come with support for this?
Darkdawg wrote a reply+100 XP
5mos ago
Darkdawg liked a comment+100 XP
5mos ago
While I agree that trans() and __() need to be able to return multiple types depending on the translation structure (string or array), that doesn’t mean a typed accessor like trans()->string() cannot exist.
This pattern already exists elsewhere in the framework: both request() and config() support strict, typed accessors (like request()->string() and config()->integer()), which throw an exception when the value doesn't match the expected type.
In fact, the trans() helper already returns the underlying Translator instance when called without arguments (trans() => app('translator')), so the API is fully capable of supporting this extension naturally:
trans()->string('messages.welcome'); // returns string or throws InvalidArgumentException
trans()->array('validation'); // returns array or throws InvalidArgumentException
Adding these typed accessors would bring Translator in line with the Config\Repository and Http\Request classes, creating a consistent, type-safe developer experience across Laravel's core repositories.
Darkdawg wrote a reply+100 XP
5mos ago
I'm sorry, that first part was rude of me, I didn't mean it that way. I appreciate the help. I'm somewhat in a learning bubble, as I started using Laravel less than a year ago.
I'll look into macros for it. I think last time I used macros for something I ran into issues with either my IDE (VS Code) or PHPStan not aknowledging the methods. I believe IDE helper solved the former, but not the latter. It's very annoying when you have to fight the tools 😅
I think the framework could really benefit from having it by default. It would be a very lightweight addition, but I'm not familiar with the process for that. PR would be the way, I guess?
Darkdawg wrote a reply+100 XP
5mos ago
No, but there's apparently packages for that: https://github.com/bladestan/bladestan
But it was just an example, I use the translation helpers several other places as well. I found the new property getters quite nifty, for example:
public string $label = 'Category' {
get => __($this->label);
}
Darkdawg wrote a reply+100 XP
5mos ago
While I agree that trans() and __() need to be able to return multiple types depending on the translation structure (string or array), that doesn’t mean a typed accessor like trans()->string() cannot exist.
This pattern already exists elsewhere in the framework: both request() and config() support strict, typed accessors (like request()->string() and config()->integer()), which throw an exception when the value doesn't match the expected type.
In fact, the trans() helper already returns the underlying Translator instance when called without arguments (trans() => app('translator')), so the API is fully capable of supporting this extension naturally:
trans()->string('messages.welcome'); // returns string or throws InvalidArgumentException
trans()->array('validation'); // returns array or throws InvalidArgumentException
Adding these typed accessors would bring Translator in line with the Config\Repository and Http\Request classes, creating a consistent, type-safe developer experience across Laravel's core repositories.
Darkdawg wrote a reply+100 XP
5mos ago
To be honest, I think that stinks. You're using something that can return an array as a string, so you're not just trying to satisfy the tool.
I don't see any reason the framework shouldn't come with trans()->string('...') or trans()->array('...') (or for the __() shorthand if you wish).
If you look at the new typed accessor APIs from Laravel 12, where they introduced exactly these things to the config() and request() helpers. Now instead of doing config('app.something') which would return mixed, you instead do config()->string('app.something') which returns string.
This should be included within the framework imo.
Darkdawg wrote a reply+100 XP
5mos ago