🔥 Tip: Add this to your AppServiceProvider to automatically use HTTPS when viewing your app in @beyondcode Expose. This can be useful for testing how your app works with HTTPS, or testing specific features which require HTTPS.
🔥 Tip: You can use CSS variables and dark mode in SVG files, including SVG files used for the favicon. 👇 This code is all you need to get a favicon that changes colors when dark mode gets enabled
🔥 Tip: You can use the <base> tag to specify defaults for your links, such as the target and root path. It can be very useful in cases where you'd otherwise have very repetitive code (e.g. all links being target="_blank"). Demo: https://t.co/VDWYtr4zDo
🔥 Tip: Use loading="lazy" on your <img> tags to defer loading until the user scrolls down to them This tells the browser to make a request only when the image is very close to the current viewport. Which makes the experience both smooth & performant https://t.co/dkh7M3yIIZ
💡 Context matters. Above I said that moving business logic to action/service classes is good. But context matters Here's code design advice from a popular "Laravel best practices" repo. There's absolutely no reason to put a 3-line check into a class. That's just overengineered
👉 Comments usually indicate poor code design. Before writing a comment, ask yourself if you could rename some things or create variables to improve readability. If that's not possible, write the comment in a way that both your colleagues and you will understand in 6 months.
👉 Write functional code when it benefits you. Functional code can both clean things up and make them impossible to understand. Refactor common loops into functional calls, but don't write stupidly complex reduce()s just to avoid writing a loop. There's a use case for both.
👉 Use collections when they can clean up your code. Don't turn all arrays into collections just because Laravel offers them, but DO turn arrays into collections when you can make use of collection syntax to clean up your code.
👉 Use docblocks only when they clarify things. Many people will disagree with this, because they do it. But it makes no sense. There's no point in using docblocks when they don't give any extra information. If the typehint is enough, don't add a docblock. That's just noise.
👉 Avoid queries in Blade when possible Sometimes you may want to execute DB queries in blade. There are some ok use cases for this, such as in layout files. But if it's a view returned by a controller, pass the data in the view data instead.
👉 Create custom Blade directives for business logic. You can make your Blade templates more expressive by creating custom directives. For example, rather than checking if the user has the admin role, you could use @admin.
👉 Use strict comparison. ALWAYS use strict comparison (=== and !==). If needed, cast things go the correct type before comparing. Better than weird == results Also consider enabling strict types in your code. This will prevent passing variables of wrong data types to functions