mirror of
https://github.com/kremalicious/blog.git
synced 2024-12-23 01:30:01 +01:00
62 lines
27 KiB
JSON
62 lines
27 KiB
JSON
|
[
|
|||
|
|
{
|
|||
|
|
"id": "2020-05-22-gatsby-redirect-from/index.md",
|
|||
|
|
"slug": "2020-05-22-gatsby-redirect-from",
|
|||
|
|
"body": "\nPlugin for [Gatsby](https://www.gatsbyjs.org) to create redirects based on a list in your Markdown frontmatter, mimicking the behavior of [jekyll-redirect-from](https://github.com/jekyll/jekyll-redirect-from).\n\n## Features\n\nBy adding a `redirect_from` list of URLs to your Markdown file's YAML frontmatter, this plugin creates client-side redirects for all of them at build time, with Gatsby's [createRedirect](https://www.gatsbyjs.org/docs/actions/#createRedirect) used under the hood.\n\nBy combining this plugin with [gatsby-plugin-meta-redirect](https://github.com/getchalk/gatsby-plugin-meta-redirect) you get simple server-side redirects from your `redirect_from` lists out of the box. You can also combine it with any other plugin picking up Gatsby `createRedirect` calls to get proper SEO-friendly [server-side redirects](#server-side-redirects) for your hosting provider.\n\n## Usage\n\nFirst, install the plugin from your project's root:\n\n```bash\ncd yourproject/\nnpm i gatsby-redirect-from gatsby-plugin-meta-redirect\n```\n\nThen add it to your `gatsby-config.js` file under `plugins`:\n\n```js title=\"gatsby-config.js\"\nplugins: [\n 'gatsby-redirect-from',\n 'gatsby-plugin-meta-redirect' // make sure this is always the last one\n]\n```\n\nThat's it for the configuration.\n\nFinally, use the key `redirect_from` followed by a list in your Markdown file's YAML frontmatter:\n\n```yaml title=\"post.md\"\n---\ntitle: Aperture File Types\nredirect_from:\n - /new-goodies-aperture-file-types-icons/\n - /goodie-updated-aperture-file-types-v11/\n - /aperture-file-types-v12-released/\n - /2008/04/aperture-file-types/\n # note: trailing slashes are required\n---\n```\n\n## Default Query\n\nPlugin assumes the default setup from [gatsby-starter-blog](https://github.com/gatsbyjs/gatsby-starter-blog), with Markdown files processed by [gatsby-transformer-remark](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-transformer-remark), and adding a field `slug` for each markdown node. Resulting in the availability of a `allMarkdownRemark` query.\n\nHead over to `gatsby-starter-blog`'s [`gatsby-node.js`](https://github.com/gatsbyjs/gatsby-starter-blog/blob/master/gatsby-node.js#L57) file to see how this is done, or follow the [Adding Markdown Pages](https://www.gatsbyjs.org/docs/adding-markdown-pages/) tutorial.\n\nOptionally, you can pass a different query to this [plugin's configuration](#options).\n\n## Server-Side Redirects\n\nGatsby's `createRedirect` only creates client-side redirects, so further integration is needed to get SEO-friendly server-side redirects or make your redirects work when users have JavaScript disabled. Which is highly dependent on your hosting provider: if you want to have the proper HTML status codes like `301`, Apache needs `.htaccess` rules for that, Nginx needs `rewrite` rules, S3 needs `RoutingRules`, Vercel needs entries in a `vercel.json`, Netlify needs a `_redirects` file, and so on.\n\nOne simple way, as suggested by default in installation, is to use [gatsby-plugin-meta-redirect](https://github.com/getchalk/gatsby-plugin-meta-redirect) to generate static HTML files with a `<meta http-equiv=\"refresh\" />` tag for every `createRedirect` call in their `<head>`. So it works out of the box with this plugin without further adjustments.\n\nThis way is the most compatible way of handling redirects, working with pretty much every hosting provider. Only catch: it's only for usability, no SEO-friendly `301` redirect is set anywhere.\n\nFor some hosting providers additional plugins are available which will pick up the redirects created by this plugin and create server-side redirects for you. Be sure to add any of those plugins after `gatsby-redirect-from` in your `gatsby-config.js`:\n\n| Provider | Plugin |\n| -------- | ----------------------------------------------------------------------------------------------------- |\n| Netlify | [gatbsy-plugin-netlify](https://www.gatsbyjs.org/
|
|||
|
|
"collection": "articles",
|
|||
|
|
"data": {
|
|||
|
|
"title": "Redirect plugin for Markdown Pages in Gatsby",
|
|||
|
|
"date": "2020-05-22T14:08:00.367Z",
|
|||
|
|
"updated": "2020-05-23T09:35:12.000Z",
|
|||
|
|
"tags": ["goodies", "gatsby", "development"],
|
|||
|
|
"toc": true,
|
|||
|
|
"changelog": "kremalicious/gatsby-redirect-from",
|
|||
|
|
"image": {
|
|||
|
|
"src": "/@fs/Users/m/Code/blog/src/content/articles/2020-05-22-gatsby-redirect-from/gatsby-redirect-from-teaser.png?origWidth=1880&origHeight=600&origFormat=png",
|
|||
|
|
"width": 1880,
|
|||
|
|
"height": 600,
|
|||
|
|
"format": "png"
|
|||
|
|
},
|
|||
|
|
"githubLink": "https://github.com/kremalicious/blog/tree/main/content/articles/2020-05-22-gatsby-redirect-from/index.md"
|
|||
|
|
}
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "2021-07-29-ocean-makes-multi-network-even-easier/index.md",
|
|||
|
|
"slug": "2021-07-29-ocean-makes-multi-network-even-easier",
|
|||
|
|
"body": "\nSimplifying Multi-Network on Ocean with a Unified Interface.\n\n---\n\n> This article was originally posted [on Medium in the Ocean Protocol blog](https://blog.oceanprotocol.com/ocean-makes-multinetwork-even-simpler-c3ec6c0cbd50).\n\n---\n\n## 🦑 The New Reality\n\nWhen we launched the Ocean Market as part of v3 we had [just moved onto ETH Mainnet](https://blog.oceanprotocol.com/oceans-on-ethereum-mainnet-ba9be1aee0ce) from our own custom PoA Mainnet, so all focus for the user interface went into working against that one production network. As we deployed the Ocean Protocol contracts to more chains to escape rapidly rising transaction fees, the main interface paradigm, of basing the displayed metadata on the user’s connected network quickly became a pain to use. Hello, _Could not retrieve asset_. 🙃\n\nSo we sat down and figured out the best patterns to solve these main pain points, focusing solely on the end user perspective:\n\n- Reduce friction when following links to assets outside of ETH Mainnet\n- Retain the DID and existing URLs as the unique identifier for an asset, regardless of network\n- Increase discoverability of assets outside of ETH Mainnet\n- Increase discoverability of all networks Ocean Protocol is deployed to\n- Encourage usage of networks beyond just ETH Mainnet\n- Reduce need to switch wallet networks as much as possible when browsing the market\n- Any possible solution needs to scale easily as we continue deploying to more networks\n\n## 🧜♀️ Multi-Network Market\n\n\n\nUltimately, we arrived at a solution tackling all this, where the main new paradigm is an interface showing assets mixed from multiple networks. All the time and on every screen where assets are listed. This detaches the metadata and financial data source from the user’s wallet network as it was before.\n\nThe displayed networks are now controlled by the new network selector.\n\n\n\nBy default, we auto-select all production networks Ocean Protocol is deployed to. As soon as you interact with this new network switcher, your selection takes over and is saved in your browser so it will be the same the next time you come to the market.\n\nSelecting or de-selecting networks then modifies all Elasticsearch queries going to our new Aquarius, resulting in mixed assets on screen.\n\n\n\nAll assets now indicate which network they belong to, and you are prompted to switch to the asset’s network when we detect your wallet being connected to another network.\n\n\n\nAnd in the case of using MetaMask, we added actions to switch your wallet network directly from the UI, which, as of right now, is pretty much the most streamlined user flow possible to switch networks with MetaMask from a Dapp.\n\nWith all this, wallet network switching is now only needed once you want to interact with an asset, like downloading or adding liquidity to its pool.\n\nUser wallet network also stays important for publishing an asset, so we based the whole publish form on the currently connected network to define onto which network an asset is published.\n\n\n\nAs for our key market statistics in the footer, we switched it to show consolidated numbers as a sum of all production networks. In its tooltip, you can find the values split up by network.\n\n\n\nMore assets on screen and more controls also led to further UI tweaks to get more space available to the actual main content. We completely refactored the main menu layout, added a global search box to it, and moved some warnings around. And, while we were at it, improved the mobile experience for it. ✨✨\n\n![
|
|||
|
|
"collection": "articles",
|
|||
|
|
"data": {
|
|||
|
|
"title": "Ocean Makes Multi-Network Even Easier",
|
|||
|
|
"date": "2021-07-29T00:00:00.000Z",
|
|||
|
|
"tags": ["oceanprotocol", "blockchain", "design", "development", "web3"],
|
|||
|
|
"toc": true,
|
|||
|
|
"image": {
|
|||
|
|
"src": "/@fs/Users/m/Code/blog/src/content/articles/2021-07-29-ocean-makes-multi-network-even-easier/ocean-makes-multi-network-even-easier-teaser.png?origWidth=2692&origHeight=1202&origFormat=png",
|
|||
|
|
"width": 2692,
|
|||
|
|
"height": 1202,
|
|||
|
|
"format": "png"
|
|||
|
|
},
|
|||
|
|
"githubLink": "https://github.com/kremalicious/blog/tree/main/content/articles/2021-07-29-ocean-makes-multi-network-even-easier/index.md"
|
|||
|
|
}
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "2023-09-18-favicon-generation-with-astro/index.md",
|
|||
|
|
"slug": "2023-09-18-favicon-generation-with-astro",
|
|||
|
|
"body": "\nThose small but impactful icons displayed next to a website's title in a browser tab seem like a minor detail, yet implementing favicons involves various considerations for different formats and sizes to fit a range of devices and browsers. Luckily, we can always count on Evil Martians to tell us [which files are needed](https://evilmartians.com/chronicles/how-to-favicon-in-2021-six-files-that-fit-most-needs) in modern times. Those findings can be implemented quite easy in Astro.\n\nThis article outlines how to implement just that with [Astro](https://astro.build), utilizing its [Static File Endpoints](https://docs.astro.build/en/core-concepts/endpoints/) and [`getImage()`](https://docs.astro.build/en/guides/images/#generating-images-with-getimage) function to generate multiple favicon sizes.\n\nThis procedure assumes you are fine with all sizes being generated from one big size. If you require more control e.g. over the smaller sizes you can use the following walkthrough as a starting point.\n\nBut you might wonder why there's a need for a dynamic approach when these images could simply be added to the `public/` directory manually.\n\nIf you're fine with never changing your favicon assets, the most simple approach would be to generate all files manually into the `public/` folder, including the `manifest.json`. And then reference them with their absolute path in your `head` as described further down, skipping the dynamic image generation and manifest creation.\n\nOne significant advantage of generating favicons dynamically is cache busting. When you update your favicon, browsers might still serve the old one from cache. By generating favicons dynamically, you can ensure that the latest version is served, as, if they have changed, each build will create new, uniquely named files that bypass the cache.\n\n## Project Structure\n\nTo begin, these are the source files we will deal with, with only 2 image assets:\n\n```\nmy-astro-project/\n├── src/\n│ ├── pages/\n│ │ └── manifest.json.ts\n│ │ └── favicon.ico.ts\n│ ├── layouts/\n│ │ └── index.astro\n│ └── images/\n│ │ └── favicon.png\n│ │ └── favicon.svg\n```\n\n- `src/images/`\\\n Housing the original favicon images. `favicon.png` is a large-sized image (512px) that will be resized dynamically, whereas `favicon.svg` can be a SVG file that adapts to the user's light or dark mode settings.\n\n- `src/layouts/index.astro`\\\n This can be any layout template or page that contains your HTML `head` content, as we will add the links to the favicons and the manifest file in there.\n\n- `src/pages/manifest.json.ts`\\\n This is an Astro Static File Endpoint that dynamically generates the `/manifest.json` file, referencing the generated favicons. This file uses Astro's `getImage()` function to create various sizes of PNG icons from a single source image, and then includes these in the generated manifest.\n\n### Final Generated Files\n\nAfter building the project, the generated favicon files will be placed in the `dist/_astro/` directory (`dist/_image/` during development) with dynamic filenames, and correctly referenced in your `head` and `/manifest.json`. This happens automatically during the site build, so there's no need to keep track of these files manually.\n\nThis should be present in your `dist/` folder after following the rest of this article:\n\n```\nmy-astro-project/\n├── dist/\n│ ├── favicon.ico\n│ ├── manifest.json\n│ ├── _astro/\n│ │ └── favicon.HASH.png\n│ │ └── favicon.HASH.png\n│ │ └── favicon.HASH.png\n│ │ └── favicon.HASH.svg\n```\n\n## Adding Favicon References to the `head`\n\nTo reference the manifest file and to generate required favicon sizes, let's update the `head` section of the site first.\n\nIn this example, we do this in a `src/layouts/index.astro` file, assuming this is then used as a shared layout in one of your `src/pages/` files. But do this wherever your `head` info g
|
|||
|
|
"collection": "articles",
|
|||
|
|
"data": {
|
|||
|
|
"title": "Favicon Generation with Astro",
|
|||
|
|
"date": "2023-09-18T00:47:30.000Z",
|
|||
|
|
"tags": ["development", "favicon", "astro"],
|
|||
|
|
"toc": true,
|
|||
|
|
"image": {
|
|||
|
|
"src": "/@fs/Users/m/Code/blog/src/content/articles/2023-09-18-favicon-generation-with-astro/favicon-generation-with-astro-teaser.png?origWidth=1880&origHeight=600&origFormat=png",
|
|||
|
|
"width": 1880,
|
|||
|
|
"height": 600,
|
|||
|
|
"format": "png"
|
|||
|
|
},
|
|||
|
|
"githubLink": "https://github.com/kremalicious/blog/tree/main/content/articles/2023-09-18-favicon-generation-with-astro/index.md"
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
]
|