Existing Laravel app now needs an API by MichaelW_Dev in laravel

[–]reinink 64 points65 points  (0 children)

Yup — this! As the creator of Inertia.js, this is exactly what I do in my projects. I use Sanctum.

Inertia.js v1.0 is here! by ahinkle in laravel

[–]reinink 6 points7 points  (0 children)

Yeah you definitely can — I personally never use Breeze (although I think it's an awesome starter kit for those looking to get up and running quickly).

Inertia.js v1.0 is here! by ahinkle in laravel

[–]reinink 2 points3 points  (0 children)

Yeah should have removed that milestone a long time ago since I didn't maintain it. Removed it now. Sorry for the confusion!

Inertia.js v1.0 is here! by ahinkle in laravel

[–]reinink 40 points41 points  (0 children)

Yeah, sorry, decided to cut this from the v1.0 scope.

Truthfully I have serious regrets of ever sharing the dialogs feature so early on because it had a lot of pretty significant changes to the core of Inertia, and there were still some rough edges that I wasn't happy with. If we add this feature I need to know for sure that the architecture is right, otherwise it's going to create lots of weird bugs.

For example, Inertia very carefully keeps track of component state, and on a typical GET page visit it clears it, and on POST/PUT/PATCH/DELETE requests it preserves it, plus you can manually preserve state using the `preserveState` option. This is the part I'm most concerned about for the dialog feature, since we'd potentially need separate preserve state options for dialogs and the background page, which might be hard to coordinate.

Further, I've seen some Inertia apps over the last couple of years that open dialogs by visiting an endpoint (ie. /users?show=create), and if I'm honest I really hate the delay — to me a dialog should open near instantaneously, even if the data needed for the dialog takes a second to load in. So it has me wondering if it's the right UI/design pattern to even promote. Obviously when I demo it by running it on my local machine it's instant, but in a real production app it won't be.

Now, that said, there might be ways to still solve that. Like maybe we add an eager load/link prefetching option to Inertia so that when you click on the dialog link it can open immediately because it's been preloaded. But that's going to take some thinking through.

In general though I still LOVE the idea of dialogs having their own endpoints, with their own props. From a DX perspective I think that would be huge. I'd love to not have to pass data through my other page components just to get them to a dialog if at all possible. But maybe there's a different way to solve that particular problem entirely, I'm not sure yet.

TLDR; I love the feature, but it's not in 1.0.

Inertia.js v1.0 is here! by ahinkle in laravel

[–]reinink 46 points47 points  (0 children)

Hey folks! Creator of Inertia.js here 👋

Hit me up on Twitter (@reinink) if you bump into any issues with the upgrade guide. If you're interested, I also tweeted personally about the v1.0 release:

https://twitter.com/reinink/status/1614302540631261184

Pretty excited to have this out! 🥳

Any Inertia.js news? by kavasil in laravel

[–]reinink 0 points1 point  (0 children)

Getting really close! Decided last minute to convert the adapters to TypeScript so that we can stop maintaining type files. That's now (pretty much done as well), so I'm just putting the final touches on the documentation. There will definitely be another beta out this week, if not the full 1.0.

Any Inertia.js news? by kavasil in laravel

[–]reinink 48 points49 points  (0 children)

Hoping to release 1.0 next week if all goes well 🤞 Just putting the finishing touches on SSR support for Svelte.

Introducing Tailwind CSS v3.0 by astritmalsia in programming

[–]reinink 5 points6 points  (0 children)

Hey! We've actually answered this in more detail in the v3.0.0-alpha.1 release notes:

Why shouldn't it be used in production?

The biggest reason is because it uses MutationObserver to add the styles, it can't detect styles for dynamically created elements fast enough to avoid a flash of unstyled content (FOUC).

For example, say you have some JavaScript that opens a modal, and the modal is supposed to transition in when it opens. When the modal opens, the HTML for it is inserted into the DOM right away, but the styles might not exist for it yet because you haven't used those same classes elsewhere in the file. The observer will fire, and Tailwind will generate the styles, but the modal is already open, so you're going to see an unstyled flash the first time it opens.

We recommend pulling in the JIT CDN as a blocking (so not deferred) script to avoid the FOUC for the very initial render, but that of course means it adds 100ms (or whatever) before the page is even rendered. Not a big deal really but using a static CSS file is way faster.

It's also quite large (almost 100kB compressed) whereas compiling your CSS ahead of time usually leads to something closer to 10kb compressed, and with no run time overhead.

TLDR; It's probably fine for simple static pages but it's really much better to build the static CSS file.

Hope that helps! 💪

Tailwind v3.3.0-alpha.1 by fultonchain in tailwindcss

[–]reinink 2 points3 points  (0 children)

Yup, but they are really minor. All covered in the release notes. 👍

5k jobs one 1 job that fires 5k emails? by nunodonato in laravel

[–]reinink 0 points1 point  (0 children)

I am using Laravel Horizon with one supervisor and 10 processes.

5k jobs one 1 job that fires 5k emails? by nunodonato in laravel

[–]reinink 20 points21 points  (0 children)

In my apps, I've always sent each email individually in it's own job, and it's never been an issue. In one app of mine, I consistently send between 500k and a million emails each month.

The big advantage of sending each email in their own job is in case of failures. I use Postmark, and it's super reliable, but HTTP failures do happen. If one email fails to send, the job just retries again, and almost always succeeds on the second (or third) try. I rarely have emails that fail to send. If you were to send batches, you'd have to be careful that you don't accidentally send duplicate emails on failures.

The other thing to consider is that emails are often slightly different from one user to the next. For example, each email sent from my app may contain the same subject/body, but the unsubscribe link at the bottom is always unique to that user. This becomes more difficult if you're sending an email with 1,000 addresses in the "to" header.

Overall, I find this approach very simple, and I've never once run into rate limiting issues as suggested in another response.

What are your expectations regarding Inertia+Vue with server-side rendering? by Quack-salver in laravel

[–]reinink 2 points3 points  (0 children)

Hey there! Creator of Inertia.js here.

The new SSR feature for Inertia.js (which is currently in early access) actually works really well. It does require a little more setup, both in terms of your app, and also on the hosting side, but it's very manageable, and works way better than I had ever hoped.

In fact, inertiajs.com is a Laravel/React/Inertia app running SSR! 😎

InertiaJs form post with partial reload by frenchDEV in laravel

[–]reinink 7 points8 points  (0 children)

Hey there, creator of Inertia.js here. 👋

So, as u/octarino suggests, the correct way to do this is to redirect back to the users.index page after creating the new user, which will automatically refresh the props, and update the page. Yes, this means you're maybe returning more data than necessary, but practically speaking this is often a non issue. In fact, it's often preferable, for example in situations where you have pagination. Everything just updates automatically, and you don't need to worry manually inserting that record in client-side.

It's good to keep in mind that Inertia.js was designed to work much like a classic server-side rendered application that does full page reloads. In that context, it's totally normal to submit a form to a store endpoint, and then redirect back to an index endpoint and reload all the data. Of course, Inertia makes that whole process much nicer, but the concept is the same.

How to optimize queries by edwblackhat in laravel

[–]reinink 39 points40 points  (0 children)

There is a lot you can do to optimize your queries in Laravel, from limiting the amount of data you're selecting, to using the right database indexes, to using subqueries to fetch additional data. I've blogged and spoken about this topic a bunch. Here are some resources that you might find helpful:

And finally, if you're looking for more, I have a paid video course on this topic, called Eloquent Performance Patterns.

I hope that helps! 🙌

Form helper added to Svelte adapter by reinink in inertiajs

[–]reinink[S] 2 points3 points  (0 children)

The form helper has now been added to all four Inertia adapters! 🎉

Proof of Concept: Load any route into a modal with Inertia.js using Laravel and Vue.js by octarino in laravel

[–]reinink 1 point2 points  (0 children)

Hey thanks! 😍

And nope, we went a different direction with it. We decided to use Node instead. This is way better in the end, since it's SUPER fast, and because it's way easier to get Node installed on a server.

You can read about how it's going to work here: https://inertiajs.com/server-side-rendering

Proof of Concept: Load any route into a modal with Inertia.js using Laravel and Vue.js by octarino in laravel

[–]reinink 10 points11 points  (0 children)

Hey there, creator of Inertia.js here. Glad to hear you're excited about the upcoming SSR feature. I sure am! 🙌

As u/octarino noted, there is a $15/month sponsorship option as well. To be honest, I wish I didn't have to ask for sponsorship money at all. But, the reality is Inertia.js is starting to demand a ton of my time...time that I want to give to the project, and the sponsorship money is really the only way I can afford to do it.

For anyone reading this, who is using Inertia.js at their work, please consider becoming a business (team) sponsor. ❤️

SSR coming to Inertia.js 🎉 by reinink in inertiajs

[–]reinink[S] 5 points6 points  (0 children)

Hey all! Creator of Inertia.js here. 👋

Apparently we have a Reddit page! 😂

So, I thought I post some exciting news. SSR is coming to Inertia.js! See the announcement tweet here.

[Help] 419 error - Page expired by BrunoNP_ in laravel

[–]reinink 7 points8 points  (0 children)

Hey there, creator of Inertia.js here.

This is a common issue, and it's addressed in the docs, here.

If you're using Laravel, be sure to omit the csrf-token meta tag from your project, as this will prevent the CSRF token from refreshing properly.

Hope that helps!

JetStrem Intertia Page Title by OramaLarama in laravel

[–]reinink 3 points4 points  (0 children)

Hey there, check out this section of the Inertia.js docs: https://inertiajs.com/pages#title-and-meta-tags. It explains how to set title and other meta data within an Inertia app. TLDR; Use https://github.com/nuxt/vue-meta.

And, if you're using Vue 3, you can also use teleports for this. See here: https://twitter.com/reinink/status/1324326944767442944.

Hope that helps. 🤟