 |
 |
 |
 |
 |
|---|---|---|---|---|
| Latest | Latest | Latest | Latest | 11+ |
 |  |  |  | ![
| // getStaticProps, which we use as the primary method for data fetching on all our pages, | |
| // runs at build time and generates page data statically. this data is not regenerated | |
| // unless the site is rebuilt, a lot like a static site generator. therefore, it's not | |
| // helpful when you are trying to live preview content changes without rebuilding the entire | |
| // site, even though its great for performance in production. | |
| // | |
| // In order to solve this, we run this script before pushing the preview version of the website, | |
| // which replaces `getStaticProps` with `getServerProps`, a method with the same signature that | |
| // dynamically fetches data fresh on every page load, making it excellent for fast-changing data, | |
| // which is just what we need for a preview environment. |
Within github, there are two things you can do to make your commits more secure both for you and for others you work with: signing your commits, and ensuring that your personal email remains private in your commits. In this piece, We'll go over each of these methods, why they are important, and how to accomplish them smoothly on Mac OSX.
Anyone who has access to a repository can push a commit to that repo under your name, and nobody will be able to tell the difference. All they have to do is change their git settings to use your name and email address for commits. Let that sink in for a minute, or if it helps more, read this piece explaining how it can turn into a serious problem. The way you can solve this problem is through signing your commits with a GPG key - when you do this, github will display a "verified" badge next to each commit. You can even set up repos so t
| new SpikeDatoCMS({ | |
| addDataTo: locals, | |
| token: 'xxx', | |
| templates: [ | |
| { | |
| collection: (dato) => dato.blogPosts, | |
| path: 'templates/post.html', | |
| output: (post) => { return `posts/${post.slug}.html` } | |
| } | |
| ] |
Spike v1 represents a significant change, mostly because it includes an update from webpack v1 to webpack v2 behind the scenes. The aim of this piece is to guide you through the process of migration from one version to the next, and explain a bit of the rationale behind these changes.
The bulk of the migration work lies in the app.js file. Webpack drastically changed its configuration in a very breaking manner between v1 and v2, so spike was forced to do the same, since spike is an extension of webpack.
| --- | |
| title: 'wow' | |
| --- | |
| hello, this is **markdown**! |
| module.exports = function (source) { | |
| console.log(this.query) // { foo: [null] } -- this is because when it's json serialized, it nulls out functions | |
| const realOptions = this.options.module.rules.reduce((m, r) => { | |
| const fooLoaderUse = r.use.find((u) => u.loader === 'foo-loader') | |
| return fooLoaderUse ? fooLoaderUse.options : m | |
| }, null) | |
| console.log(realOptions) // foo: [() => 'bar'] -- it works, but is v. ugly | |
| } |
| /** | |
| * @param {number} n - integer (n >= 0) | |
| * @param {number} d - digit (0 <= d <= 9) | |
| * square all numbers k between 0 and n (0 <= k <= n) | |
| * count the number of digits d used in the k*k's | |
| * example | |
| * | |
| * n = 10 | |
| * d = 1 |
| extend(src='layout.sgr') | |
| block(name='content') | |
| .post(md). | |
| # A markdown post | |
| Here you can write **pure markdown** without issue. | |
| You can treat this entire block like it's a normal markdown file and it will be compiled as such. Pretty cool! Everything works -- headlines, links, etc. | |
| .footnote What's nice is that if you need to inject some extra html, javascript, add another block to change the title, etc. this is very simple to do since you have the capability to write full html with a reshape file as opposed to markdown. |
npm i greenkeeper -g, run: gk enablenpm i npm-check -g, run: npm-check -upackage.json file to make sure it has important fields, organizes fields consistently