// Next.js comes with built-in support for environment variables. | |
// https://nextjs.org/docs/basic-features/environment-variables | |
module.exports = { | |
env: { | |
LOCAL_API_ENDPOINT: process.env.LOCAL_API_ENDPOINT, | |
}, | |
} |
<template> | |
<div id="google_translate_element" /> | |
</template> | |
<script> | |
import { Policy } from 'cockatiel' | |
import { includeJsOnce, injectStyles } from '@/utils' | |
export function initTranslate() { | |
includeJsOnce({ |
The N+1 query problem is a common performance antipattern. It looks like this:
$cats = load_cats();
foreach ($cats as $cat) {
$cats_hats = load_hats_for_cat($cat);
// ...
}
Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite.
If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If however you have the ability to reason logically about the salient changes diff by prescient diff — where by definition each prescient diff represents nothing but the salient changes — then you at least stand a fighting chance of version N+1 having fewer bugs than version N while also moving your business forwards.
<template> | |
<div v-if="isTimeToRender"> | |
<slot /> | |
</div> | |
</template> | |
<script> | |
export default { | |
props: { | |
timeToRender: { type: Number, default: 300 }, |