Merge branch 'workaround-gatsby-node' into headings-with-id-plugin
# Conflicts: # package-lock.json # package.json # plugins/count-inline-code/gatsby-node.js
@@ -1,5 +1,5 @@
|
||||
<p align="center">
|
||||
<img alt="Unicorn Utterances logo" width="256" src="./content/assets/unicorn-utterances-logo-512.png"/>
|
||||
<img alt="Unicorn Utterances logo" width="256" src="./src/assets/unicorn_utterances_logo_512.png"/>
|
||||
</p>
|
||||
<h1 align="center">
|
||||
Unicorn Utterances Website
|
||||
@@ -40,7 +40,7 @@ You should then have an `index.md` file containing a frontmatter (with JS
|
||||
header, not YAML) portion and any related files should be in the same folder.
|
||||
|
||||
### Author Data File
|
||||
The author data file is located at [`src/data/unicorns.json`](./src/data/unicorns.json) 🦄
|
||||
The author data file is located at [`content/data/unicorns.json`](./content/data/unicorns.json) 🦄
|
||||
|
||||
To add yourself as an author in a PR for a new post, you'd add your information
|
||||
as a new JSON object in the array, then add a profile picture to the `data`
|
||||
@@ -49,7 +49,7 @@ yours is not listed, please add it as a new value in that file, we've tried to
|
||||
do our best to include everything we've found!)
|
||||
|
||||
> If you do not want to show a profile picture or commit your picture to
|
||||
the repo, we have a [myriad of emotes that can be used as profile pictures as well](./content/assets/branding/emotes).
|
||||
the repo, we have a [myriad of emotes that can be used as profile pictures as well](https://github.com/unicorn-utterances/design-assets/tree/master/emotes).
|
||||
They're adorable, go check! 🤩
|
||||
|
||||
## 🚀 Develop
|
||||
|
||||
@@ -1,403 +0,0 @@
|
||||
Attribution-NonCommercial-NoDerivatives 4.0 International
|
||||
|
||||
=======================================================================
|
||||
|
||||
Creative Commons Corporation ("Creative Commons") is not a law firm and
|
||||
does not provide legal services or legal advice. Distribution of
|
||||
Creative Commons public licenses does not create a lawyer-client or
|
||||
other relationship. Creative Commons makes its licenses and related
|
||||
information available on an "as-is" basis. Creative Commons gives no
|
||||
warranties regarding its licenses, any material licensed under their
|
||||
terms and conditions, or any related information. Creative Commons
|
||||
disclaims all liability for damages resulting from their use to the
|
||||
fullest extent possible.
|
||||
|
||||
Using Creative Commons Public Licenses
|
||||
|
||||
Creative Commons public licenses provide a standard set of terms and
|
||||
conditions that creators and other rights holders may use to share
|
||||
original works of authorship and other material subject to copyright
|
||||
and certain other rights specified in the public license below. The
|
||||
following considerations are for informational purposes only, are not
|
||||
exhaustive, and do not form part of our licenses.
|
||||
|
||||
Considerations for licensors: Our public licenses are
|
||||
intended for use by those authorized to give the public
|
||||
permission to use material in ways otherwise restricted by
|
||||
copyright and certain other rights. Our licenses are
|
||||
irrevocable. Licensors should read and understand the terms
|
||||
and conditions of the license they choose before applying it.
|
||||
Licensors should also secure all rights necessary before
|
||||
applying our licenses so that the public can reuse the
|
||||
material as expected. Licensors should clearly mark any
|
||||
material not subject to the license. This includes other CC-
|
||||
licensed material, or material used under an exception or
|
||||
limitation to copyright. More considerations for licensors:
|
||||
wiki.creativecommons.org/Considerations_for_licensors
|
||||
|
||||
Considerations for the public: By using one of our public
|
||||
licenses, a licensor grants the public permission to use the
|
||||
licensed material under specified terms and conditions. If
|
||||
the licensor's permission is not necessary for any reason--for
|
||||
example, because of any applicable exception or limitation to
|
||||
copyright--then that use is not regulated by the license. Our
|
||||
licenses grant only permissions under copyright and certain
|
||||
other rights that a licensor has authority to grant. Use of
|
||||
the licensed material may still be restricted for other
|
||||
reasons, including because others have copyright or other
|
||||
rights in the material. A licensor may make special requests,
|
||||
such as asking that all changes be marked or described.
|
||||
Although not required by our licenses, you are encouraged to
|
||||
respect those requests where reasonable. More considerations
|
||||
for the public:
|
||||
wiki.creativecommons.org/Considerations_for_licensees
|
||||
|
||||
=======================================================================
|
||||
|
||||
Creative Commons Attribution-NonCommercial-NoDerivatives 4.0
|
||||
International Public License
|
||||
|
||||
By exercising the Licensed Rights (defined below), You accept and agree
|
||||
to be bound by the terms and conditions of this Creative Commons
|
||||
Attribution-NonCommercial-NoDerivatives 4.0 International Public
|
||||
License ("Public License"). To the extent this Public License may be
|
||||
interpreted as a contract, You are granted the Licensed Rights in
|
||||
consideration of Your acceptance of these terms and conditions, and the
|
||||
Licensor grants You such rights in consideration of benefits the
|
||||
Licensor receives from making the Licensed Material available under
|
||||
these terms and conditions.
|
||||
|
||||
|
||||
Section 1 -- Definitions.
|
||||
|
||||
a. Adapted Material means material subject to Copyright and Similar
|
||||
Rights that is derived from or based upon the Licensed Material
|
||||
and in which the Licensed Material is translated, altered,
|
||||
arranged, transformed, or otherwise modified in a manner requiring
|
||||
permission under the Copyright and Similar Rights held by the
|
||||
Licensor. For purposes of this Public License, where the Licensed
|
||||
Material is a musical work, performance, or sound recording,
|
||||
Adapted Material is always produced where the Licensed Material is
|
||||
synched in timed relation with a moving image.
|
||||
|
||||
b. Copyright and Similar Rights means copyright and/or similar rights
|
||||
closely related to copyright including, without limitation,
|
||||
performance, broadcast, sound recording, and Sui Generis Database
|
||||
Rights, without regard to how the rights are labeled or
|
||||
categorized. For purposes of this Public License, the rights
|
||||
specified in Section 2(b)(1)-(2) are not Copyright and Similar
|
||||
Rights.
|
||||
|
||||
c. Effective Technological Measures means those measures that, in the
|
||||
absence of proper authority, may not be circumvented under laws
|
||||
fulfilling obligations under Article 11 of the WIPO Copyright
|
||||
Treaty adopted on December 20, 1996, and/or similar international
|
||||
agreements.
|
||||
|
||||
d. Exceptions and Limitations means fair use, fair dealing, and/or
|
||||
any other exception or limitation to Copyright and Similar Rights
|
||||
that applies to Your use of the Licensed Material.
|
||||
|
||||
e. Licensed Material means the artistic or literary work, database,
|
||||
or other material to which the Licensor applied this Public
|
||||
License.
|
||||
|
||||
f. Licensed Rights means the rights granted to You subject to the
|
||||
terms and conditions of this Public License, which are limited to
|
||||
all Copyright and Similar Rights that apply to Your use of the
|
||||
Licensed Material and that the Licensor has authority to license.
|
||||
|
||||
g. Licensor means the individual(s) or entity(ies) granting rights
|
||||
under this Public License.
|
||||
|
||||
h. NonCommercial means not primarily intended for or directed towards
|
||||
commercial advantage or monetary compensation. For purposes of
|
||||
this Public License, the exchange of the Licensed Material for
|
||||
other material subject to Copyright and Similar Rights by digital
|
||||
file-sharing or similar means is NonCommercial provided there is
|
||||
no payment of monetary compensation in connection with the
|
||||
exchange.
|
||||
|
||||
i. Share means to provide material to the public by any means or
|
||||
process that requires permission under the Licensed Rights, such
|
||||
as reproduction, public display, public performance, distribution,
|
||||
dissemination, communication, or importation, and to make material
|
||||
available to the public including in ways that members of the
|
||||
public may access the material from a place and at a time
|
||||
individually chosen by them.
|
||||
|
||||
j. Sui Generis Database Rights means rights other than copyright
|
||||
resulting from Directive 96/9/EC of the European Parliament and of
|
||||
the Council of 11 March 1996 on the legal protection of databases,
|
||||
as amended and/or succeeded, as well as other essentially
|
||||
equivalent rights anywhere in the world.
|
||||
|
||||
k. You means the individual or entity exercising the Licensed Rights
|
||||
under this Public License. Your has a corresponding meaning.
|
||||
|
||||
|
||||
Section 2 -- Scope.
|
||||
|
||||
a. License grant.
|
||||
|
||||
1. Subject to the terms and conditions of this Public License,
|
||||
the Licensor hereby grants You a worldwide, royalty-free,
|
||||
non-sublicensable, non-exclusive, irrevocable license to
|
||||
exercise the Licensed Rights in the Licensed Material to:
|
||||
|
||||
a. reproduce and Share the Licensed Material, in whole or
|
||||
in part, for NonCommercial purposes only; and
|
||||
|
||||
b. produce and reproduce, but not Share, Adapted Material
|
||||
for NonCommercial purposes only.
|
||||
|
||||
2. Exceptions and Limitations. For the avoidance of doubt, where
|
||||
Exceptions and Limitations apply to Your use, this Public
|
||||
License does not apply, and You do not need to comply with
|
||||
its terms and conditions.
|
||||
|
||||
3. Term. The term of this Public License is specified in Section
|
||||
6(a).
|
||||
|
||||
4. Media and formats; technical modifications allowed. The
|
||||
Licensor authorizes You to exercise the Licensed Rights in
|
||||
all media and formats whether now known or hereafter created,
|
||||
and to make technical modifications necessary to do so. The
|
||||
Licensor waives and/or agrees not to assert any right or
|
||||
authority to forbid You from making technical modifications
|
||||
necessary to exercise the Licensed Rights, including
|
||||
technical modifications necessary to circumvent Effective
|
||||
Technological Measures. For purposes of this Public License,
|
||||
simply making modifications authorized by this Section 2(a)
|
||||
(4) never produces Adapted Material.
|
||||
|
||||
5. Downstream recipients.
|
||||
|
||||
a. Offer from the Licensor -- Licensed Material. Every
|
||||
recipient of the Licensed Material automatically
|
||||
receives an offer from the Licensor to exercise the
|
||||
Licensed Rights under the terms and conditions of this
|
||||
Public License.
|
||||
|
||||
b. No downstream restrictions. You may not offer or impose
|
||||
any additional or different terms or conditions on, or
|
||||
apply any Effective Technological Measures to, the
|
||||
Licensed Material if doing so restricts exercise of the
|
||||
Licensed Rights by any recipient of the Licensed
|
||||
Material.
|
||||
|
||||
6. No endorsement. Nothing in this Public License constitutes or
|
||||
may be construed as permission to assert or imply that You
|
||||
are, or that Your use of the Licensed Material is, connected
|
||||
with, or sponsored, endorsed, or granted official status by,
|
||||
the Licensor or others designated to receive attribution as
|
||||
provided in Section 3(a)(1)(A)(i).
|
||||
|
||||
b. Other rights.
|
||||
|
||||
1. Moral rights, such as the right of integrity, are not
|
||||
licensed under this Public License, nor are publicity,
|
||||
privacy, and/or other similar personality rights; however, to
|
||||
the extent possible, the Licensor waives and/or agrees not to
|
||||
assert any such rights held by the Licensor to the limited
|
||||
extent necessary to allow You to exercise the Licensed
|
||||
Rights, but not otherwise.
|
||||
|
||||
2. Patent and trademark rights are not licensed under this
|
||||
Public License.
|
||||
|
||||
3. To the extent possible, the Licensor waives any right to
|
||||
collect royalties from You for the exercise of the Licensed
|
||||
Rights, whether directly or through a collecting society
|
||||
under any voluntary or waivable statutory or compulsory
|
||||
licensing scheme. In all other cases the Licensor expressly
|
||||
reserves any right to collect such royalties, including when
|
||||
the Licensed Material is used other than for NonCommercial
|
||||
purposes.
|
||||
|
||||
|
||||
Section 3 -- License Conditions.
|
||||
|
||||
Your exercise of the Licensed Rights is expressly made subject to the
|
||||
following conditions.
|
||||
|
||||
a. Attribution.
|
||||
|
||||
1. If You Share the Licensed Material, You must:
|
||||
|
||||
a. retain the following if it is supplied by the Licensor
|
||||
with the Licensed Material:
|
||||
|
||||
i. identification of the creator(s) of the Licensed
|
||||
Material and any others designated to receive
|
||||
attribution, in any reasonable manner requested by
|
||||
the Licensor (including by pseudonym if
|
||||
designated);
|
||||
|
||||
ii. a copyright notice;
|
||||
|
||||
iii. a notice that refers to this Public License;
|
||||
|
||||
iv. a notice that refers to the disclaimer of
|
||||
warranties;
|
||||
|
||||
v. a URI or hyperlink to the Licensed Material to the
|
||||
extent reasonably practicable;
|
||||
|
||||
b. indicate if You modified the Licensed Material and
|
||||
retain an indication of any previous modifications; and
|
||||
|
||||
c. indicate the Licensed Material is licensed under this
|
||||
Public License, and include the text of, or the URI or
|
||||
hyperlink to, this Public License.
|
||||
|
||||
For the avoidance of doubt, You do not have permission under
|
||||
this Public License to Share Adapted Material.
|
||||
|
||||
2. You may satisfy the conditions in Section 3(a)(1) in any
|
||||
reasonable manner based on the medium, means, and context in
|
||||
which You Share the Licensed Material. For example, it may be
|
||||
reasonable to satisfy the conditions by providing a URI or
|
||||
hyperlink to a resource that includes the required
|
||||
information.
|
||||
|
||||
3. If requested by the Licensor, You must remove any of the
|
||||
information required by Section 3(a)(1)(A) to the extent
|
||||
reasonably practicable.
|
||||
|
||||
|
||||
Section 4 -- Sui Generis Database Rights.
|
||||
|
||||
Where the Licensed Rights include Sui Generis Database Rights that
|
||||
apply to Your use of the Licensed Material:
|
||||
|
||||
a. for the avoidance of doubt, Section 2(a)(1) grants You the right
|
||||
to extract, reuse, reproduce, and Share all or a substantial
|
||||
portion of the contents of the database for NonCommercial purposes
|
||||
only and provided You do not Share Adapted Material;
|
||||
|
||||
b. if You include all or a substantial portion of the database
|
||||
contents in a database in which You have Sui Generis Database
|
||||
Rights, then the database in which You have Sui Generis Database
|
||||
Rights (but not its individual contents) is Adapted Material; and
|
||||
|
||||
c. You must comply with the conditions in Section 3(a) if You Share
|
||||
all or a substantial portion of the contents of the database.
|
||||
|
||||
For the avoidance of doubt, this Section 4 supplements and does not
|
||||
replace Your obligations under this Public License where the Licensed
|
||||
Rights include other Copyright and Similar Rights.
|
||||
|
||||
|
||||
Section 5 -- Disclaimer of Warranties and Limitation of Liability.
|
||||
|
||||
a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
|
||||
EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
|
||||
AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
|
||||
ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
|
||||
IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
|
||||
WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
|
||||
PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
|
||||
ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
|
||||
KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
|
||||
ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
|
||||
|
||||
b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
|
||||
TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
|
||||
NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
|
||||
INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
|
||||
COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
|
||||
USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
|
||||
ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
|
||||
DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
|
||||
IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
|
||||
|
||||
c. The disclaimer of warranties and limitation of liability provided
|
||||
above shall be interpreted in a manner that, to the extent
|
||||
possible, most closely approximates an absolute disclaimer and
|
||||
waiver of all liability.
|
||||
|
||||
|
||||
Section 6 -- Term and Termination.
|
||||
|
||||
a. This Public License applies for the term of the Copyright and
|
||||
Similar Rights licensed here. However, if You fail to comply with
|
||||
this Public License, then Your rights under this Public License
|
||||
terminate automatically.
|
||||
|
||||
b. Where Your right to use the Licensed Material has terminated under
|
||||
Section 6(a), it reinstates:
|
||||
|
||||
1. automatically as of the date the violation is cured, provided
|
||||
it is cured within 30 days of Your discovery of the
|
||||
violation; or
|
||||
|
||||
2. upon express reinstatement by the Licensor.
|
||||
|
||||
For the avoidance of doubt, this Section 6(b) does not affect any
|
||||
right the Licensor may have to seek remedies for Your violations
|
||||
of this Public License.
|
||||
|
||||
c. For the avoidance of doubt, the Licensor may also offer the
|
||||
Licensed Material under separate terms or conditions or stop
|
||||
distributing the Licensed Material at any time; however, doing so
|
||||
will not terminate this Public License.
|
||||
|
||||
d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
|
||||
License.
|
||||
|
||||
|
||||
Section 7 -- Other Terms and Conditions.
|
||||
|
||||
a. The Licensor shall not be bound by any additional or different
|
||||
terms or conditions communicated by You unless expressly agreed.
|
||||
|
||||
b. Any arrangements, understandings, or agreements regarding the
|
||||
Licensed Material not stated herein are separate from and
|
||||
independent of the terms and conditions of this Public License.
|
||||
|
||||
|
||||
Section 8 -- Interpretation.
|
||||
|
||||
a. For the avoidance of doubt, this Public License does not, and
|
||||
shall not be interpreted to, reduce, limit, restrict, or impose
|
||||
conditions on any use of the Licensed Material that could lawfully
|
||||
be made without permission under this Public License.
|
||||
|
||||
b. To the extent possible, if any provision of this Public License is
|
||||
deemed unenforceable, it shall be automatically reformed to the
|
||||
minimum extent necessary to make it enforceable. If the provision
|
||||
cannot be reformed, it shall be severed from this Public License
|
||||
without affecting the enforceability of the remaining terms and
|
||||
conditions.
|
||||
|
||||
c. No term or condition of this Public License will be waived and no
|
||||
failure to comply consented to unless expressly agreed to by the
|
||||
Licensor.
|
||||
|
||||
d. Nothing in this Public License constitutes or may be interpreted
|
||||
as a limitation upon, or waiver of, any privileges and immunities
|
||||
that apply to the Licensor or You, including from the legal
|
||||
processes of any jurisdiction or authority.
|
||||
|
||||
=======================================================================
|
||||
|
||||
Creative Commons is not a party to its public
|
||||
licenses. Notwithstanding, Creative Commons may elect to apply one of
|
||||
its public licenses to material it publishes and in those instances
|
||||
will be considered the “Licensor.” The text of the Creative Commons
|
||||
public licenses is dedicated to the public domain under the CC0 Public
|
||||
Domain Dedication. Except for the limited purpose of indicating that
|
||||
material is shared under a Creative Commons public license or as
|
||||
otherwise permitted by the Creative Commons policies published at
|
||||
creativecommons.org/policies, Creative Commons does not authorize the
|
||||
use of the trademark "Creative Commons" or any other trademark or logo
|
||||
of Creative Commons without its prior written consent including,
|
||||
without limitation, in connection with any unauthorized modifications
|
||||
to any of its public licenses or any other arrangements,
|
||||
understandings, or agreements concerning use of licensed material. For
|
||||
the avoidance of doubt, this paragraph does not form part of the
|
||||
public licenses.
|
||||
|
||||
Creative Commons may be contacted at creativecommons.org.
|
||||
|
||||
@@ -436,8 +436,6 @@ _The browser takes the items that've been defined in HTML and turns them into a
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
This tree tells the browser where to place items and includes some logic when combined with CSS, even. For example, when the following CSS is applied to the `index.html` file:
|
||||
|
||||
```css
|
||||
@@ -452,6 +450,7 @@ It finds the element with the ID of `b`, then the children of that tag are color
|
||||
|
||||
> The `ul` element is marked as green just to showcase that it is the element being marked by the first part of the selector
|
||||
|
||||
> If you want to have a better grasp on the DOM and how it relates to the content you see on-screen, [check out our article that outlines what the DOM is and how your code interfaces with it through the browser](/posts/understanding-the-dom/).
|
||||
|
||||
## View Hierarchy Tree
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ There are a lot of ways that information can be connected and transferred. We us
|
||||
|
||||
_Computers speak in `1`s and `0`s, known as binary_. These binary values come in incredibly long strings of combinations of one of the two symbols to _construct all of the data used in communication_.
|
||||
|
||||
> [We covered how these two numbers can be combined to turn into other data in another post](https://unicorn-utterances.com/posts/non-decimal-numbers-in-tech/). For a better understanding of how binary represents data, check out that post.
|
||||
> [We covered how these two numbers can be combined to turn into other data in another post](/posts/non-decimal-numbers-in-tech/). For a better understanding of how binary represents data, check out that post.
|
||||
|
||||
This is true regardless of the architecture used to send data - it’s all binary under-the-hood somewhere in the process. The architecture used to send data is simply a way of organizing the ones and zeros effectively to enable the types of communication required for a specific use-case.
|
||||
|
||||
@@ -98,7 +98,7 @@ Let's start from the bottom and make our way up. Remember that each of these lay
|
||||
|
||||
The physical layer is similar to the trucks, roads, and workers that are driving to send the data. Sure, you could send a letter just by handing letters one-by-one from driver to driver, but without some organization that's usually dispatched to higher levels, things can go wrong (as they often do [in a game of telephone](https://en.wikipedia.org/wiki/Chinese_whispers)).
|
||||
|
||||
In the technical world, _this layer refers to the binary bits themselves_ ([which compose to makeup letters and the rest of structure to your data](https://unicorn-utterances.com/posts/non-decimal-numbers-in-tech/)) _and the physical wiring_ constructed to transfer those bits. As it is with the mail world, this layer alone _can_ be used alone, but often needs delegation from higher layers to be more effective.
|
||||
In the technical world, _this layer refers to the binary bits themselves_ ([which compose to makeup letters and the rest of structure to your data](/posts/non-decimal-numbers-in-tech/)) _and the physical wiring_ constructed to transfer those bits. As it is with the mail world, this layer alone _can_ be used alone, but often needs delegation from higher layers to be more effective.
|
||||
|
||||
## Data Link {#osi-layer-2-data-link}
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 8.6 KiB After Width: | Height: | Size: 8.6 KiB |
|
Before Width: | Height: | Size: 49 KiB After Width: | Height: | Size: 49 KiB |
|
Before Width: | Height: | Size: 7.8 KiB After Width: | Height: | Size: 7.8 KiB |
|
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 54 KiB |
|
Before Width: | Height: | Size: 92 KiB After Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 7.6 KiB After Width: | Height: | Size: 7.6 KiB |
|
Before Width: | Height: | Size: 98 KiB After Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 72 KiB |
|
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 30 KiB |
@@ -52,27 +52,27 @@ However, if you seek fidelity, you’ll find that `lineHeight` on Android differ
|
||||
|
||||
Let us take a look at some examples; one with a single line, then two lines, then three lines with line height set to `24pt/sp`.
|
||||
|
||||

|
||||

|
||||
|
||||
As you can probably tell, Android `TextViews` are always smaller than the ones given to a developer from a design tool and those implemented on the web. In reality, Android’s `lineHeight` is not line-height at all! **It’s just a smart version of line-spacing.**
|
||||
|
||||

|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
Now you might ask yourself, “*How can I calculate the height of each `TextView`, then?*”
|
||||
|
||||
When you use a `TextView`, it has one parameter turned on by default: **`includeFontPadding`**. `includeFontPadding` increases the height of a `TextView` to give room to ascenders and descenders that might not fit within the regular bounds.
|
||||
|
||||

|
||||

|
||||
|
||||
Now that we know how Android’s typography works, let’s look at an example.
|
||||
|
||||
Here’s a simple mockup, detailing the spacing between a title and a subtitle. It is built at `1x`, with Figma, meaning line height defines the final height of a text box — not the text size. (This is how most design tools work)
|
||||
|
||||

|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
*Of course, because it’s Android, the line height has no effect on the height of the `TextView`, and the layout is therefore `8dp` too short of the mockups.*
|
||||
|
||||
@@ -82,7 +82,7 @@ But even if it did have an effect, the problems wouldn’t stop there; the issue
|
||||
|
||||
Designers, like myself, like to see perfect alignment. We like consistent values and visual rhythm.
|
||||
|
||||

|
||||

|
||||
|
||||
Unfortunately, translating values from a design tool wasn’t possible. You had the option to either pixel nudge (pictured above, right), or forget about alignment altogether, thus leading to an incorrect implementation that would, yet again, be shorter than the mockups.
|
||||
|
||||
@@ -90,13 +90,13 @@ Unfortunately, translating values from a design tool wasn’t possible. You had
|
||||
|
||||
_`firstBaselineToTopHeight`_ and _`lastBaselineToBottomHeight`_ are powerful tools for Android design. They do as the name suggests: If _`firstBaselineToTopHeight`_ is set to `56sp`, then that’ll become the distance between the first baseline and the top of a `TextView`.
|
||||
|
||||

|
||||

|
||||
|
||||
This means that designers, alongside developers, can force the bounds of a `TextView` to match the design specs and open the door to perfect implementations of their mockups.
|
||||
|
||||
This is something I’ve personally tested in an app I designed. [**Memoire**, a note-taking app](http://tiny.cc/getmemoire) for Android, is a 1:1 recreation of its mockups — for every single screen. This was made possible due to these APIs — *and because [**@sasikanth**](https://twitter.com/its\_sasikanth) is not confrontational* — since text is what almost always makes baseline alignment and hard grids impossible to implement in production.
|
||||
|
||||
`video: title: "Near-perfect duplication of guidelines against Memoire's mockups and actual app": ./images/Memoire_Bounds_and_Baselines.mp4`
|
||||
`video: title: "Near-perfect duplication of guidelines against Memoire's mockups and actual app": ./memoire_bounds_and_baselines.mp4`
|
||||
|
||||
*Memoire’s TextViews are all customized using these APIs.*
|
||||
|
||||
@@ -104,7 +104,7 @@ This is something I’ve personally tested in an app I designed. [**Memoire**, a
|
||||
|
||||
In reality, the new attributes were actually made to be used when creating layouts: you want to make sure the baseline is a certain distance from another element, and it also helps to align the first and lastBaseline to a `4dp` grid. This mirrors the way iOS layouts are built.
|
||||
|
||||

|
||||

|
||||
|
||||
**However, there’s one giant flaw: You can’t align a `TextView`’s `firstBaseline` to another `TextView`’s `lastBaseline`.** So a problem immediately arises due to this limitation:
|
||||
|
||||
@@ -112,13 +112,13 @@ In reality, the new attributes were actually made to be used when creating layou
|
||||
|
||||
As you might imagine, **if we want to keep our text aligned to a baseline grid, we need to ensure that the height of each `TextView` is a multiple of 4 while doing so.** This means we must apply first and lastBaseline attributes to both / all of the stacked TextViews — and that becomes hard to maintain.
|
||||
|
||||

|
||||

|
||||
|
||||
|✅ Good|🛑 Bad|
|
||||
|--|--|
|
||||
|Applying `firstBaseline` and `lastBaseline` in styles allows you to know exactly what the distance between baselines is, without having to set them one by one to ensure they properly align to a `4dp` grid. | Without applying `firstBaseline` and `lastBaseline` in styles, you can’t detect what the default values are, so you are forced to apply these one by one to every `TextView` to ensure they align to a `4dp` grid. |
|
||||
|
||||
`video: title: "A comparison of how text spacing is applied on iOS and Android": ./images/iOS_vs_Android.mp4`
|
||||
`video: title: "A comparison of how text spacing is applied on iOS and Android": ./ios_vs_android.mp4`
|
||||
|
||||
The solution is to apply them in your `styles.xml` so that, when themed, the `TextView` is given the right text size, height, font, and baseline properties.
|
||||
|
||||
@@ -128,7 +128,7 @@ The solution is to apply them in your `styles.xml` so that, when themed, the `Te
|
||||
|
||||
The overrides will take precedence to whatever value you set in your **`styles.xml`**, requiring you to hunt down occurrences until you can find a layout that was broken due to the change. Let’s look at an example:
|
||||
|
||||
`video: title: "Allowing margin changes instead will let the text grow to it's expected sie without having issues with the baseline not being centered": ./images/Dont_Override.mp4`
|
||||
`video: title: "Allowing margin changes instead will let the text grow to it's expected sie without having issues with the baseline not being centered": ./dont_override.mp4`
|
||||
|
||||
Implementing margins instead of overriding values also matches the way layouts work within Android Studio and design tools like Sketch and Figma. It also ensures that your layouts can scale well to different font sizes.
|
||||
|
||||
@@ -138,7 +138,7 @@ It’s actually pretty simple. Let’s walk through how to adapt one of Material
|
||||
|
||||
**Step 1: Place a text box of the text style you’d like to adapt — in this case, Headline 6.**
|
||||
|
||||

|
||||

|
||||
|
||||
*Text box within Figma.*
|
||||
|
||||
@@ -146,7 +146,7 @@ Here we can see that the text box has a height of `32`. This is inherited from t
|
||||
|
||||
> Headline 6 = `20` (text size) `* 1.33` (`includeFontPadding`) = `26.667sp`
|
||||
|
||||

|
||||

|
||||
|
||||
*`TextView` on Android.*
|
||||
|
||||
@@ -154,27 +154,27 @@ Now resize your Figma text box to `26.6` — *it will round it to `27`, but that
|
||||
|
||||
**Step 2: With the resized text box, align its baseline with the nearest `4dp` breakpoint in your grid.**
|
||||
|
||||

|
||||

|
||||
|
||||
*Baseline now sits on the `4dp` grid.*
|
||||
|
||||
**Step 3: Measure the distance between the baseline and the top and bottom of the text box.**
|
||||
|
||||

|
||||

|
||||
|
||||
*`firstBaselineToTopHeight`: `20.66` | `lastBaselineToBottomHeight`: `6.0`*
|
||||
|
||||
**Step 4: Now right click the text box and select Frame Selection.**
|
||||
|
||||

|
||||

|
||||
|
||||
*When created from an object, a frame’s dimensions are dependent on the content inside it.*
|
||||
|
||||
**Step 5: While holding Ctrl / Command, drag the frame handles and resize it so that the top and bottom align with the nearest baselines beyond the minimum values.**
|
||||
|
||||

|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
**NOTE: Keep in mind we must not resize the text box with it. Holding Ctrl / Command is very, very important.**
|
||||
|
||||
@@ -184,23 +184,23 @@ The same thing was done to the last baseline and the bottom; we changed it from
|
||||
|
||||
**Step 6: Select the text box inside the frame, and set the text to Grow Vertically.**
|
||||
|
||||

|
||||

|
||||
|
||||
This will cause the text box to return to its original height of `32sp` — inherited from the line height.
|
||||
|
||||

|
||||

|
||||
|
||||
*The text box is 1sp down from the frame, but that’s normal. We no longer care about the text box height.*
|
||||
|
||||
**Step 7: With the text box selected, set its constraints to *Left & Right* and *Top & Bottom*.**
|
||||
|
||||

|
||||

|
||||
|
||||
*Now your text box will resize with your frame. This is essential when using the text components.*
|
||||
|
||||
You would need to find these values for every text style in your app, but if you’re taking the Material Design Type Spec as a base for your own, I have already measured and picked the right values for each! _**Resources at the end.**_
|
||||
|
||||

|
||||

|
||||
|
||||
## How to implement these values (as a developer)
|
||||
|
||||
@@ -227,7 +227,7 @@ We first set up a `TextAppearance` — which your app probably already has —
|
||||
|
||||
Let’s use Memoire once again as an example.
|
||||
|
||||

|
||||

|
||||
|
||||
### Each has a different function:
|
||||
|
||||
@@ -238,7 +238,7 @@ For example, _**`textAppearanceCaption`**_, _**`textAppearanceBody1`**_, etc.
|
||||
|
||||
**`TextStyle`:** Applied to `TextView`s in layouts, to ensure `4dp` alignment.
|
||||
|
||||

|
||||

|
||||
|
||||
*What happens to a `TextView` when a `TextStyle` is properly applied.*
|
||||
|
||||
@@ -252,7 +252,7 @@ When setting a style to a `TextView`, keep in mind that `firstBaseline` and `las
|
||||
|
||||
Applying a `TextStyle` to a component — instead of a `TextAppearance` — causes serious issues.
|
||||
|
||||

|
||||

|
||||
|
||||
*Uh-oh…*
|
||||
|
||||
@@ -264,7 +264,7 @@ As far as other issues, I haven’t been able to find any.
|
||||
|
||||
Now that you’ve scrolled all the way down without reading a single word, here’s all the stuff you’ll need:
|
||||
|
||||

|
||||

|
||||
|
||||
*Figma document with code and layout samples.*
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 317 KiB After Width: | Height: | Size: 317 KiB |
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 49 KiB After Width: | Height: | Size: 49 KiB |
|
Before Width: | Height: | Size: 80 KiB After Width: | Height: | Size: 80 KiB |
|
Before Width: | Height: | Size: 1.4 MiB After Width: | Height: | Size: 1.4 MiB |
|
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 7.5 KiB After Width: | Height: | Size: 7.5 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 9.8 KiB After Width: | Height: | Size: 9.8 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 60 KiB After Width: | Height: | Size: 60 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 53 KiB After Width: | Height: | Size: 53 KiB |
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
|
Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 63 KiB |
@@ -30,11 +30,11 @@ Unfortunately, I've had difficulties getting the same Android Studio development
|
||||
|
||||
- The other folder is one that lives under `Assets` called `AndroidCode`, which contains copied-and-pasted files from `AndroidStudioDev` that are only the related source files I need to call.
|
||||
|
||||

|
||||

|
||||
|
||||
Once the copying of the files from the Android Studio environment to `Assets` has finished, you'll need to mark it as being included in the Android build within Unity's inspector window that comes up when you highlight the source file.
|
||||
|
||||

|
||||

|
||||
|
||||
> If you forget to do this, your class or file may not be found. This is an important step to keep in mind during debugging.
|
||||
|
||||
@@ -56,11 +56,11 @@ Luckily for us, managing Android code dependencies in Unity has a thought-out so
|
||||
|
||||
In your project, you'll then want to select `Assets > Import Package > Custom Package` in order to import the downloaded plugin.
|
||||
|
||||

|
||||

|
||||
|
||||
Then, you'll see a dialog screen that'll ask what files you want to import with your Unity Package. Ensure that all of the files are selected, then press "Import".
|
||||
|
||||

|
||||

|
||||
|
||||
> Your screen may look slightly different from the one above. That's okay — so long as all of the files are selected, pressing "Import" is perfectly fine.
|
||||
|
||||
@@ -93,7 +93,7 @@ The only rule with this file structure is that your file must end with `Dependen
|
||||
|
||||
After creating the files, in the menubar, go to `Assets > Play Services Resolver > Android Resolver > Resolve`, and it should go fetch the AAR files related to those specific libraries and download them.
|
||||
|
||||

|
||||

|
||||
|
||||
So long as your file ends with `Dependencies.xml`, it should be picked up by the plugin to resolve the AAR files.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 202 KiB After Width: | Height: | Size: 202 KiB |
|
Before Width: | Height: | Size: 64 KiB After Width: | Height: | Size: 64 KiB |
@@ -57,7 +57,7 @@ Just like CSS, JavaScript is normally written in a separate file and connected b
|
||||
|
||||
As I said before, JavaScript is a for-real programming language. That means it has arrays, for loops, if-else statements, and lots of other computer science-y things going on. Despite that, the language is actually very beginner-friendly. You don’t have to have a degree in computer science or arcane mathematics to get started with a programming language. And because of the way JavaScript interacts with web browsers, you will be to do some amazing things pretty quickly.
|
||||
|
||||
One thing that makes JavaScript unique is [its ability to manipulate the DOM](https://unicorn-utterances.com/posts/understanding-the-dom/). The Document Object Model (or DOM) is an API (advanced programming interface) that allows JavaScript to manipulate the HTML and CSS of a website as the user navigates around the page and uses its features. Basically, the web browser can read JavaScript and make changes to the look, feel, and even the structure of the page in real-time.
|
||||
One thing that makes JavaScript unique is [its ability to manipulate the DOM](/posts/understanding-the-dom/). The Document Object Model (or DOM) is an API (advanced programming interface) that allows JavaScript to manipulate the HTML and CSS of a website as the user navigates around the page and uses its features. Basically, the web browser can read JavaScript and make changes to the look, feel, and even the structure of the page in real-time.
|
||||
|
||||
To go back to our building construction analogy… well, it starts to break down at this point. Imagine if you could wave a magic wand and turn the wood siding on your building into bricks. Or change the color of the building from gray to bright blue. Remember the steel beams of HTML our building is made of on the inside? By using the DOM, JavaScript can change those too!
|
||||
|
||||
@@ -68,6 +68,6 @@ JavaScript is a powerful tool that can be used to create everything from useful
|
||||
|
||||
Now you should have a better conceptual understanding of the primary web technologies, what they do, and how they work together to create the internet that we see and use every day. Once you learn the basics of HTML, CSS, and JavaScript, you will have a firm foundation to build on to create your own websites and applications.
|
||||
|
||||
You can also read more about how your browser understands and utilizes HTML and CSS in order to display content and handle user interaction under-the-hood on [another post on the site](https://unicorn-utterances.com/posts/understanding-the-dom/).
|
||||
You can also read more about how your browser understands and utilizes HTML and CSS in order to display content and handle user interaction under-the-hood on [another post on the site](/posts/understanding-the-dom/).
|
||||
|
||||
Finally, you're always able to [join our Discord](https://discord.gg/FMcvc6T) if you have any questions or comments while you're learning. All are welcome!
|
||||
|
||||
@@ -214,6 +214,6 @@ Essentially, I just want to make sure to iterate that while there may be tools t
|
||||
|
||||
And with that, we have a better understanding of what TypeScript is! I hope this has been informative and helpful for those that may be new to the language in particular. What'd you learn, let us know!
|
||||
|
||||
Now that you're more familiar with TypeScript, maybe you'd like to play around with one of their more experienced functionality: [Type generics](https://unicorn-utterances.com/posts/typescript-type-generics/)? We have a whole post around that concept as well, [you can find that here](https://unicorn-utterances.com/posts/typescript-type-generics/).
|
||||
Now that you're more familiar with TypeScript, maybe you'd like to play around with one of their more experienced functionality: [Type generics](/posts/typescript-type-generics/)? We have a whole post around that concept as well, [you can find that here](https://unicorn-utterances.com/posts/typescript-type-generics/).
|
||||
|
||||
Thanks for reading! Leave any questions or feedback in the comments below.
|
||||
|
||||
BIN
content/blog/making-an-angular-blog-with-scully/dist-folders.png
Normal file
|
After Width: | Height: | Size: 115 KiB |
|
After Width: | Height: | Size: 19 KiB |
480
content/blog/making-an-angular-blog-with-scully/index.md
Normal file
@@ -0,0 +1,480 @@
|
||||
---
|
||||
{
|
||||
title: "Building an Angular Blog With Scully",
|
||||
description: "While React and Vue have options like NuxtJS and Gatsby, Angular has previously not been able to make a SSG-enabled blog... Until now. Join us as we build one with Scully!",
|
||||
published: '2020-03-17T05:12:03.284Z',
|
||||
authors: ['crutchcorn'],
|
||||
tags: ['angular', 'ssg', 'scully'],
|
||||
attached: [],
|
||||
license: 'cc-by-nc-sa-4'
|
||||
}
|
||||
---
|
||||
|
||||
If you've ever used something like [Gatsby](https://www.gatsbyjs.org/) or [NuxtJS](https://nuxtjs.org/), you may already be familiar with Static Site Generation (SSG). If not, here's a quick rundown: You're able to export a React application to simple HTML and CSS during a build-step. This export means that (in some cases), you can disable JavaScript and still navigate your website as if you'd had it enabled. It also often means much faster time-to-interactive times, as you no longer have to run your JavaScript to render your HTML and CSS.
|
||||
|
||||
For a long time, React and Vue have had all of the SSG fun... Until now.
|
||||
|
||||
Recently, a group of extremely knowledgeable developers has created [Scully, a static site generator for Angular projects](https://github.com/scullyio/scully). If you prefer Angular for your stack, you too can join in the fun! You can even trivially migrate existing Angular projects to use Scully!
|
||||
|
||||
In this article, we'll outline how to set up a new blog post site using Scully. If you have an existing blog site that you'd like to migrate to use Scully, the blog post should help you understand some of the steps you'll need to take as well.
|
||||
|
||||
Without further ado, let's jump in, shall we?
|
||||
|
||||
# Initial Setup {#initial-setup}
|
||||
|
||||
First, we have some requirements:
|
||||
|
||||
- Node 12
|
||||
- Angular CLI installed globally
|
||||
|
||||
You're able to do this using `npm i -g @angular/cli`. You'll want to make sure you're using the latest version if you already have it pre-installed.
|
||||
|
||||
Now that we have that covered let's generate our project!
|
||||
|
||||
```
|
||||
ng new my-scully-blog
|
||||
```
|
||||
|
||||
|
||||
We'll want to choose `y` when it asks us to add routing. The second question that will be raised is regarding what flavor of CSS you'd like. I like `SCSS`, so I chose that, but you're free to select any of the options that you deem fit for your blog.
|
||||
|
||||
If we pause here and run `ng serve`, we'll find ourselves greeted with the default generated app screen from the Angular core team upon visiting the `localhost:4200` URI in our browser.
|
||||
|
||||
The file that this code lives under is the `app.component.html` file. We'll be modifying that code later on, as we don't want that UI to display on our blog site.
|
||||
|
||||
## Adding Scully {#adding-scully}
|
||||
|
||||
After that, open the `my-scully-blog` directory and run the following command to install and add Scully to the project:
|
||||
|
||||
```
|
||||
ng add @scullyio/init
|
||||
```
|
||||
|
||||
This will yield us some changed files. You'll see a new `scully.my-scully-blog.config.js` file that will help us configure Scully. You'll also notice that your `package.json` file has been updated to include two new commands:
|
||||
|
||||
```
|
||||
"scully": "scully",
|
||||
"scully:serve": "scully serve"
|
||||
```
|
||||
|
||||
Here's where the "SSG" portion of Scully comes into play. You see, once you run `ng build` to build your application, you should be running `npm run scully` to run the static generation. That way, it will generate the HTML and CSS that your Angular code will generate on the client ahead-of-time. This means that you have one more build step, but it can be incredibly beneficial for your site's speed and usability.
|
||||
|
||||
We'll need to run the `npm run scully` command later on, but for now, let's focus on adding Markdown support to our blog:
|
||||
|
||||
# Adding Markdown Support
|
||||
|
||||
While Scully [_does_ have a generator to add in blog support](https://github.com/scullyio/scully/blob/master/docs/blog.md), we're going to add it in manually. Not only will this force us to understand our actions a bit more to familiarize ourselves with how Scully works, but it means this article is not reliant on the whims of a changing generator.
|
||||
|
||||
> This isn't a stab at Scully by any means, if anything I mean it as a compliment. The team consistently improves Scully and I had some suggestions for the blog generator at the time of writing. While I'm unsure of these suggestions making it into future versions, it'd sure stink to throw away an article if they were implemented.
|
||||
|
||||
## Angular Routes {#angular-blog-routes}
|
||||
|
||||
Before we get into adding in the Scully configs, let's first set up the page that we'll want our blog to show up within. We want a `/blog` sub route, allowing us to have a `/blog` for the list of all posts and a `/blog/:postId` for the individual posts.
|
||||
|
||||
We'll start by generating the `blog` module that will hold our routes and components.
|
||||
|
||||
```
|
||||
ng g module blog --route=blog --routing=true --module=App
|
||||
```
|
||||
|
||||
This will create a route called `blog` and generate or modify the following files:
|
||||
|
||||
```
|
||||
CREATE src/app/blog/blog-routing.module.ts (341 bytes)
|
||||
CREATE src/app/blog/blog.module.ts (344 bytes)
|
||||
CREATE src/app/blog/blog.component.scss (0 bytes)
|
||||
CREATE src/app/blog/blog.component.html (21 bytes)
|
||||
CREATE src/app/blog/blog.component.spec.ts (622 bytes)
|
||||
CREATE src/app/blog/blog.component.ts (275 bytes)
|
||||
UPDATE src/app/app-routing.module.ts (433 bytes)
|
||||
```
|
||||
|
||||
If you look under your `app-routing.module.ts` file, you'll see that we have a new route defined:
|
||||
|
||||
```typescript
|
||||
const routes: Routes = [
|
||||
{
|
||||
path: "blog",
|
||||
loadChildren: () =>
|
||||
import("./blog/blog.module").then(m => m.BlogModule)
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
This imports the `blog.module` file to use the further children routes defined there. If we now start serving the site and go to `localhost:4200/blog`, we should see the message "blog works!" at the bottom of the page.
|
||||
|
||||
### Routing Fixes {#router-outlet}
|
||||
|
||||
That said, you'll still be seeing the rest of the page. That's far from ideal, so let's remove the additional code in `app.component.html` to be only the following:
|
||||
|
||||
```html
|
||||
<router-outlet></router-outlet>
|
||||
```
|
||||
|
||||
Now, on the `/blog` route, we should _only_ see the "blog works" message!
|
||||
|
||||
However, if you go to `localhost:4200/`, you'll see nothing there. Let's add a new component to fix that.
|
||||
|
||||
```
|
||||
ng g component homepage -m App
|
||||
```
|
||||
|
||||
This will create a new `homepage` component under `src/app/homepage`. It's only got a basic HTML file with `homepage works!` present, but it'll suffice for now. Now we just need to update the `app-routing.module.ts` file to tell it that we want this to be our new home route:
|
||||
```typescript
|
||||
import { HomepageComponent } from "./homepage/homepage.component";
|
||||
|
||||
const routes: Routes = [
|
||||
{
|
||||
path: "blog",
|
||||
loadChildren: () =>
|
||||
import("./blog/blog.module").then(m => m.BlogModule)
|
||||
},
|
||||
{
|
||||
path: "",
|
||||
component: HomepageComponent
|
||||
}
|
||||
];
|
||||
```
|
||||
|
||||
Now, we have both `/blog` and `/` working as-expected!
|
||||
|
||||
### Adding Blog Post Route {#blog-post-route}
|
||||
|
||||
Just as we added a new route to the existing `/` route, we're going to do the same thing now, but with `/blog` paths. Let's add a `blog-post` route to match an ID passed to `blog`. While we won't hookup any logic to grab the blog post by ID yet, it'll help to have that route configured.
|
||||
|
||||
```
|
||||
ng g component blog/blog-post -m blog
|
||||
```
|
||||
|
||||
Then, we'll need to add that path to the blog list:
|
||||
|
||||
```typescript
|
||||
const routes: Routes = [
|
||||
{ path: ":postId", component: BlogPostComponent },
|
||||
{ path: "", component: BlogComponent }
|
||||
];
|
||||
```
|
||||
|
||||
That's it! Now, if you go to `localhost:4200/blog`, you should see the `blog works!` message and on the `/blog/asdf` route, you should see `blog-post works!`. With this, we should be able to move onto the next steps!
|
||||
|
||||
|
||||
## The Markdown Files {#frontmatter}
|
||||
|
||||
To start, let's create a new folder at the root of your project called `blog`. It's in this root folder that we'll add our markdown files that our blog posts will live in. Let's create a new markdown file under `/blog/test-post.md`.
|
||||
|
||||
```markdown
|
||||
---
|
||||
title: Test post
|
||||
description: This is a post description
|
||||
publish: true
|
||||
---
|
||||
|
||||
# Hello, World
|
||||
|
||||
How are you doing?
|
||||
```
|
||||
|
||||
> Keep in mind that the file name will be the URL for the blog post later on. In this case, the URL for this post will be `/blog/test-post`.
|
||||
|
||||
The top of the file `---` block is called the "frontmatter"_. You're able to put metadata in this block with a key/value pair. We're then able to use that metadata in the Angular code to generate specific UI based on this information in the markdown file. Knowing that we can store arbitrary metadata in this frontmatter allows us to expand the current frontmatter with some useful information:
|
||||
|
||||
```markdown
|
||||
---
|
||||
title: Test post
|
||||
description: This is a post description
|
||||
publish: true
|
||||
authorName: Corbin Crutchley
|
||||
authorTwitter: crutchcorn
|
||||
---
|
||||
```
|
||||
|
||||
It's worth mentioning that the `publish` property has some built-in functionality with Scully that we'll see later on. We'll likely want to leave that field in and keep it `true` for now.
|
||||
|
||||
## Scully Routes {#scully-blog-route-config}
|
||||
|
||||
Now we'll tell Scully to generate one route for each markdown file inside of our `blog` folder. As such, we'll update our `scully.my-scully-blog.config.js` file to generate a new `/blog/:postId` route for each of the markdown files:
|
||||
|
||||
```javascript
|
||||
exports.config = {
|
||||
// This was generated by the `ng add @scullyio/init`
|
||||
projectRoot: "./src",
|
||||
projectName: "my-scully-blog",
|
||||
outDir: './dist/static',
|
||||
// This is new
|
||||
routes: {
|
||||
'/blog/:postId': {
|
||||
type: 'contentFolder',
|
||||
postId: {
|
||||
folder: "./blog"
|
||||
}
|
||||
},
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
Before we start the build process and run Scully, let's add one more change to our `blog-post.component.html` file:
|
||||
|
||||
```html
|
||||
<h1>My Blog Post</h1>
|
||||
<hr>
|
||||
<!-- This is where Scully will inject the static HTML -->
|
||||
<scully-content></scully-content>
|
||||
<hr>
|
||||
<h2>End of content</h2>
|
||||
```
|
||||
|
||||
Adding in the `scully-content` tags will allow Scully to inject the HTML that's generated from the related Markdown post into that tag location. To register this component in Angular, we also need to update our `blog.module.ts` file to add an import:
|
||||
|
||||
```typescript
|
||||
import {ScullyLibModule} from '@scullyio/ng-lib';
|
||||
|
||||
@NgModule({
|
||||
declarations: [BlogComponent, BlogPostComponent],
|
||||
imports: [CommonModule, BlogRoutingModule, ScullyLibModule]
|
||||
})
|
||||
export class BlogModule {}
|
||||
```
|
||||
|
||||
You'll notice that if you run `ng serve` at this stage and try to access `localhost:4200/blog/test-post`, you'll see... Not the blog post. You'll see something like:
|
||||
|
||||
```html
|
||||
<h1>Sorry, could not parse static page content</h1>
|
||||
<p>This might happen if you are not using the static generated pages.</p>
|
||||
```
|
||||
|
||||
This message is showing because we're not able to get the HTML of the markdown; we haven't statically generated the site to do so. Scully injects the markdown's HTML at build time, so we're unable to get the contents of the markdown file during the development mode. We _can_ get the route metadata from the frontmatter on the blog post, however. If you want to learn more about that, you'll have to read the next section. 😉
|
||||
|
||||
# Running the Build
|
||||
|
||||
> Even if you're familiar with Angular's build process, you should read this section! Scully does some non-standard behavior that will prevent some of the steps in the next sections if not understood properly.
|
||||
|
||||
Now that we have our code configured to generate routes based on our Markdown files let's run `ng build`. The build should go off without a hitch if the code was updated alongside the post.
|
||||
|
||||
> If you hit an error at this step, make sure to read through the steps again and pay attention to the error messages. Angular does a decent job of indicating what you need to change to get the build working again.
|
||||
|
||||
Now, let's run `npm run scully`; Doing so should give us some message like this:
|
||||
|
||||
```
|
||||
Route "" rendered into file: "/Users/ccrutchley/git/my-scully-blog/dist/static/index.html"
|
||||
Route "/blog" rendered into file: "/Users/ccrutchley/git/my-scully-blog/dist/static/blog/index.html"
|
||||
Route "/blog/2020-03-12-blog" rendered into file: "/Users/ccrutchley/git/my-scully-blog/dist/static/blog/2020-03-12-blog/index.html"
|
||||
send reload
|
||||
```
|
||||
|
||||
> "ScullyIO not generating markdown blog post route" is something I've attempted to Google multiple times.
|
||||
>
|
||||
> If you happen to see an error like `Pull in data to create additional routes.
|
||||
> missing config for parameters (postId) in route: /blog/:postId. Skipping
|
||||
> Route list created in files` you've misconfigured your `scully.config.js` file.
|
||||
>
|
||||
> For example, at one point I had the following code in my config file when I was getting that error:
|
||||
>
|
||||
> ```javascript
|
||||
> '/blog/:postId': {
|
||||
> type: 'contentFolder',
|
||||
> slug: {
|
||||
> folder: "./blog"
|
||||
> }
|
||||
> },
|
||||
> ```
|
||||
>
|
||||
> The problem is that the route and the config are mismatched. You need to configure it to look like this:
|
||||
>
|
||||
> ```javascript
|
||||
> '/blog/:postId': {
|
||||
> type: 'contentFolder',
|
||||
> postId: {
|
||||
> folder: "./blog"
|
||||
> }
|
||||
> },
|
||||
> ```
|
||||
>
|
||||
> Making sure that your params match like this should generate the pages as-expected.
|
||||
|
||||
Now, we can access the server at the bottom of the build output:
|
||||
|
||||
```
|
||||
The server is available on "http://localhost:1668/"
|
||||
```
|
||||
|
||||
Finally, if we go to [http://localhost:1668/blog/test-post](http://localhost:1668/blog/test-post), we can see the post contents alongside our header and footer.
|
||||
|
||||

|
||||
|
||||
## Scully Build Additions {#scully-build-folder}
|
||||
|
||||
You'll notice that if you open your `dist` folder, you'll find two folders:
|
||||
|
||||
- `my-scully-blog`
|
||||
- `static`
|
||||
|
||||

|
||||
|
||||
The reason for the two separate folders is because Scully has it's own build folder. When you ran `ng build`, you generated the `my-scully-blog` folder, then when you later ran `npm run scully`, it generated the `static` folder. As such, if you want to host your app, you should use the `static` folder.
|
||||
|
||||
## Asset Routes {#scully-build-routes}
|
||||
|
||||
If you open the `/src/assets` folder, you'll notice another file you didn't have before `npm run scully`. This file is generated any time you run Scully and provides you the routing metadata during an `ng serve` session. [Remember how I mentioned that there was a way to access the Markdown frontmatter data?](#scully-blog-route-config) Well, this is how! After running a Scully build, you'll be provided metadata at your disposal. In the next section, we'll walk through how to access that metadata!
|
||||
|
||||
# Listing Posts {#scully-route-acess}
|
||||
|
||||
To get a list of posts, we're going to utilize Scully's route information service. To start, let's add that service to the `blog.component.ts` file:
|
||||
|
||||
```typescript
|
||||
import { Component, OnInit } from '@angular/core';
|
||||
import { ScullyRoutesService } from '@scullyio/ng-lib';
|
||||
|
||||
@Component({
|
||||
selector: 'app-blog',
|
||||
templateUrl: './blog.component.html',
|
||||
styleUrls: ['./blog.component.scss']
|
||||
})
|
||||
export class BlogComponent implements OnInit {
|
||||
constructor(private scully: ScullyRoutesService) {}
|
||||
|
||||
ngOnInit(): void {
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now that we have access to said service, we can add some calls inside of our `ngOnInit` lifecycle method to list out the routes:
|
||||
|
||||
```typescript
|
||||
ngOnInit(): void {
|
||||
this.scully.available$.subscribe(routes => console.log(routes));
|
||||
}
|
||||
```
|
||||
|
||||
If you now start your server (`ng serve`) and load up your `/blog` route, you should see the following printed out to your log:
|
||||
|
||||
```javascript
|
||||
0: {route: "/"}
|
||||
1: {route: "/blog/test-post", title: "Test post", description: "This is a post description", publish: true, authorName: "Corbin Crutchley", …}
|
||||
2: {route: "/blog"}
|
||||
```
|
||||
|
||||
See? We're able to see all of the routes that Scully generated during the last `npm run scully` post-build step. Additionally, any of the routes that were generated from a markdown file contains it's frontmatter!
|
||||
|
||||
> [Remember how I said earlier that the frontmatter fields impacted Scully?](#frontmatter) Well, that `publish` field will toggle if a route shows up in this list or not. If you change that field to `false`, then rebuild and re-run the `scully` command, it will hide it from this list.
|
||||
>
|
||||
> Want to list **all** of the routes, including the ones with `publish: false`? Well, change `this.scully.available$` to `this.scully.allRoutes$`, and you'll even have those in the fray!
|
||||
|
||||
We now have the list of routes, but surely we don't want to list the `/blog` or the `/` routes, do we? Simple enough, let's add a filter:
|
||||
|
||||
```typescript
|
||||
routes.filter(route =>
|
||||
route.route.startsWith('/blog/') && route.sourceFile.endsWith('.md')
|
||||
);
|
||||
```
|
||||
|
||||
And that'll give us what we're looking for:
|
||||
|
||||
```javascript
|
||||
0: {route: "/blog/test-post", title: "Test post", description: "This is a post description", publish: true, authorName: "Corbin Crutchley", …}
|
||||
```
|
||||
|
||||
## Final Blog List {#scully-avail-routes}
|
||||
|
||||
We can cleanup the code a bit by using [the Angular `async` pipe](https://angular.io/api/common/AsyncPipe):
|
||||
|
||||
```typescript
|
||||
// blog.component.ts
|
||||
import { Component } from '@angular/core';
|
||||
import { ScullyRoutesService } from '@scullyio/ng-lib';
|
||||
import { map } from 'rxjs/operators';
|
||||
|
||||
@Component({
|
||||
selector: 'app-blog',
|
||||
templateUrl: './blog.component.html',
|
||||
styleUrls: ['./blog.component.scss']
|
||||
})
|
||||
export class BlogComponent {
|
||||
constructor(private scully: ScullyRoutesService) {}
|
||||
|
||||
$blogPosts = this.scully.available$.pipe(
|
||||
map(routes =>
|
||||
routes.filter(
|
||||
route =>
|
||||
route.route.startsWith('/blog/') && route.sourceFile.endsWith('.md')
|
||||
)
|
||||
)
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
```html
|
||||
<!-- blog.component.html -->
|
||||
<ul aria-label="Blog posts">
|
||||
<li *ngFor="let blog of $blogPosts | async">
|
||||
<a [routerLink]="blog.route">
|
||||
{{blog.title}} by {{blog.authorName}}
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
This code should give us a straight list of blog posts and turn them into links for us to access our posts with!
|
||||
|
||||

|
||||
|
||||
While this isn't a pretty blog, it is a functional one! Now you're able to list routes; we can even get the metadata for a post
|
||||
|
||||
## Final Blog Post Page {#scully-avail-routes-filtered}
|
||||
|
||||
But what happens if you want to display metadata about a post on the post page itself? Surely being able to list the author metadata in the post would be useful as well, right?
|
||||
|
||||
Right you are! Using [RxJS' `combineLatest` function](https://rxjs.dev/api/index/function/combineLatest) and [the `ActivatedRoute`'s `params` property](https://angular.io/api/router/ActivatedRoute#params) (alongside [the RxJS `pluck` opperator](https://rxjs.dev/api/operators/pluck) to make things a bit easier for ourselves), we're able to quickly grab a post's metadata from the post page itself.
|
||||
|
||||
```typescript
|
||||
// blog-post.component.ts
|
||||
import { Component } from '@angular/core';
|
||||
import { ActivatedRoute } from '@angular/router';
|
||||
import { ScullyRoutesService } from '@scullyio/ng-lib';
|
||||
import { combineLatest } from 'rxjs';
|
||||
import { map, pluck } from 'rxjs/operators';
|
||||
|
||||
@Component({
|
||||
selector: 'app-blog-post',
|
||||
templateUrl: './blog-post.component.html',
|
||||
styleUrls: ['./blog-post.component.scss']
|
||||
})
|
||||
export class BlogPostComponent {
|
||||
constructor(
|
||||
private activatedRoute: ActivatedRoute,
|
||||
private scully: ScullyRoutesService
|
||||
) {}
|
||||
|
||||
$blogPostMetadata = combineLatest([
|
||||
this.activatedRoute.params.pipe(pluck('postId')),
|
||||
this.scully.available$
|
||||
]).pipe(
|
||||
map(([postId, routes]) =>
|
||||
routes.find(route => route.route === `/blog/${postId}`)
|
||||
)
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
```html
|
||||
<!-- blog-post.component.html -->
|
||||
<h1 *ngIf="$blogPostMetadata | async as blogPost">Blog Post by {{blogPost.authorName}}</h1>
|
||||
<hr>
|
||||
<!-- This is where Scully will inject the static HTML -->
|
||||
<scully-content></scully-content>
|
||||
<hr>
|
||||
<h2>End of content</h2>
|
||||
```
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Conclusion
|
||||
|
||||
While this blog site is far from ready from release, it's functional. It's missing some core SEO functionality as well as general aesthetics, but that could be easily remedied. Using a package like [`ngx-meta`](https://www.npmjs.com/package/@ngx-meta/core) should allow you to make short work of the SEO meta tags that you're missing where areas adding some CSS should go a long way with the visuals of the site.
|
||||
|
||||
All in all, Scully proves to be a powerful tool in any Angular developer's toolkit, and knowing how to make a blog with it is just one use case for such a tool.
|
||||
|
||||
As always, I'd love to hear from you down below in our comments or even [in our community Discord](https://discord.gg/FMcvc6T). Also, don't forget to subscribe to our newsletter so you don't miss more content like this in the future!
|
||||
|
After Width: | Height: | Size: 155 KiB |
|
After Width: | Height: | Size: 76 KiB |
@@ -12,7 +12,7 @@
|
||||
|
||||
Any web application relies on some fundamental technologies: HTML, CSS, and JavaScript. Even advanced front-end JavaScript frameworks such as Angular, React, or Vue will utilize some level of HTML to load the JavaScript. That said, how the browser handles HTML and CSS under-the-hood can be quite the mystery. In this article, I'm going to explain what the browser does to understand what it should show to the user.
|
||||
|
||||
> If you're unfamiliar with HTML, CSS, or JavaScript, you may want to take a look at [our post that introduces these three items](https://unicorn-utterances.com/posts/intro-to-html-css-and-javascript). They'll provide a good foundation for this article for newcomers to the programming scene or folks who may not be familiar with what those languages do.
|
||||
> If you're unfamiliar with HTML, CSS, or JavaScript, you may want to take a look at [our post that introduces these three items](/posts/intro-to-html-css-and-javascript). They'll provide a good foundation for this article for newcomers to the programming scene or folks who may not be familiar with what those languages do.
|
||||
|
||||
# The DOM {#the-dom}
|
||||
|
||||
|
||||
1
content/blog/what-is-ssr-and-ssg/csr.svg
Normal file
|
After Width: | Height: | Size: 50 KiB |
130
content/blog/what-is-ssr-and-ssg/index.md
Normal file
@@ -0,0 +1,130 @@
|
||||
---
|
||||
{
|
||||
title: "What is Server Side Rendering (SSR) and Static Site Generation (SSG)?",
|
||||
description: "An explanation of what server-side rendering is, what static site generation is, and how you can utilize them in React, Angular, or Vue!",
|
||||
published: '2020-03-30T05:12:03.284Z',
|
||||
authors: ['crutchcorn'],
|
||||
tags: ['ssr', 'ssg', 'nextjs', 'react'],
|
||||
attached: [],
|
||||
license: 'cc-by-nc-sa-4'
|
||||
}
|
||||
---
|
||||
|
||||
In recent years, projects like [Zeit's NextJS](https://nextjs.org/) and [Gatsby](https://www.gatsbyjs.org/) have garnered acclaim and higher and higher usage numbers. Not only that, but their core concepts of Server Side Rendering (SSR) and Static Site Generation (SSG) have been seen in other projects and frameworks such as [Angular Universal](https://angular.io/guide/universal), [ScullyIO](https://scully.io/), and [NuxtJS](https://nuxtjs.org/). Why is that? What _is_ SSR and SSG? How can I use these concepts in my applications?
|
||||
|
||||
We'll walk through all of these questions and provide answers for each. First, we have to have an understanding of how a typical HTML site is able to serve content to your user.
|
||||
|
||||
# Vanilla HTML Sites
|
||||
|
||||
While many sites today are built using a component-based framework like Angular, React, or Vue, there's nothing wrong with good ole' HTML. For sites like this, you typically provide an HTML file for each of the routes of your site. When the user requests one of the routes, your server will return the HTML for it. From there, [your browser parses that code and provides the content directly to the user](/posts/understanding-the-dom/). All in all, the process looks something like this:
|
||||
|
||||
1) You build HTML, CSS, JS
|
||||
2) You put it on a server
|
||||
3) The client downloads the HTML, CSS, JS from server
|
||||
4) The client immediately sees content on screen
|
||||
|
||||

|
||||
|
||||
This is a reasonably straightforward flow once you get the hang of it. Let's take a look at what happens when you throw a component-based framework into the fray.
|
||||
|
||||
# Client Side Rendering {#csr}
|
||||
|
||||
While you may not be familiar with this term, you're more than likely familiar with how you'd implement one of these; After all, this is the default when building an Angular, React, or Vue site. Let's use a React site as an example. When you build a typical React SPA without utilizing a framework like NextJS or Gatsby, you'd:
|
||||
|
||||
1) You build the React code
|
||||
2) You put it on a server
|
||||
3) The client downloads the React code from the server
|
||||
4) The React code runs and generates the HTML/CSS on the client's computer
|
||||
5) The user **then** sees the content on screen after React runs
|
||||
|
||||

|
||||
|
||||
This is because React's code has to initialize to render the components on screen before it can spit out HTML for the browser to parse. Sure, there's an initial HTML file that might have loading spinner, but until your components have time to render, that's hardly useful content for your user. _While these load times can be sufficient for smaller applications_, if you have many components loading on-screen, _you may be in trouble if you want to keep your time-to-interactive (TTI) low_. That scenario is where SSR often comes into play.
|
||||
|
||||
# Server Side Rendering (SSR) {#ssr}
|
||||
|
||||
Because React has to initialize _somewhere_, what if we were to move the initial rendering off to the server? Imagine - for each request the user sends your way, you spin up an instance of React. Then, you're able to serve up the initial render (also called "fully hydrated") HTML and CSS to the user, ready to roll. That's just what server-side rendering is!
|
||||
|
||||
1) You build the React code
|
||||
2) You put it on a server
|
||||
3) The client requests data
|
||||
4) The server runs the React code on the server to generate the HTML/CSS
|
||||
5) The server then sends the generated HTML/CSS on screen
|
||||
6) The user then sees the content on screen. React doesn't have to run on their computer
|
||||
|
||||

|
||||
|
||||
There are more improvements than there might initially see, however! Because you're hosting from a server - which has better network connectivity than a user's machine - you're able to make much faster network requests to perform that initial render.
|
||||
|
||||
Say you need to grab data from the database to populate the screen's data, you're able to do that much faster as a result. Instead of displaying the user a loading screen while you wait to grab the data, you can simply tell your client, "don't show anything until I send you HTML that I've generated from React." Due to the speed of your network, you can typically ship down a hydrated UI from database data as quickly as you'd typically be able to display a spinner.
|
||||
|
||||
Moreover, if you have your server and database in the same hosting location, you're even able to avoid out-of-intranet calls, which would provide faster, more reliable connectivity for your initial render.
|
||||
|
||||
That said because you're relying on server functionality to do this rendering, you have to have a custom server setup. No simple CDN hosting here - your server has to initialize and render each user's page on request.
|
||||
|
||||
# Static Site Generation (SSG) {#ssg}
|
||||
|
||||
If SSR is ["passing the buck"](https://en.wikipedia.org/wiki/Buck_passing) to the server to generate the initial page, then SSG is passing the buck to you - the developer.
|
||||
|
||||
While the industry widely recognizes the term "Static Site Generation," I prefer the term "compile-side rendering" or "compile-time server-side rendering." This is because I feel they outline a better explanation of the flow of displaying content to the user. On an SSG site, you'd:
|
||||
|
||||
1) You build the React code
|
||||
2) You generate the HTML and CSS on your development machine before deploying to a server (run build)
|
||||
3) You put the generated built code on a server
|
||||
4) The client downloads the HTML, CSS, JS from the built code on the server
|
||||
5) The client immediately sees content on screen
|
||||
|
||||

|
||||
|
||||
This simply extends the existing build process that many front-end frameworks have. After [Babel's done with its transpilation](https://babeljs.io/), it merely executes code to compile your initial screen into static HTML and CSS. This isn't entirely dissimilar from how SSR hydrates your initial screen, but it's done at compile-time, not at request time.
|
||||
|
||||
Since you're only hosting HTML and CSS again, you're able to host your site as you would a client-side rendered app: Using a CDN. This means that you can geo-sparse your hosting much more trivially but comes with the caveat that you're no longer to do rapid network queries to generate the UI as you could with SSR.
|
||||
|
||||
# Pros and Cons {#pros-and-cons}
|
||||
|
||||
It may be tempting to look through these options, find one that you think is the best, and [overfit](https://en.wiktionary.org/wiki/overfit) yourself into a conclusion that one is superior to all the others. That said, each of these methods has its strengths and weaknesses.
|
||||
|
||||
|
||||
| Tool | Pros | Cons |
|
||||
| ---------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
| Vanilla HTM | <ul aria-label="HTML Pros"><li>Fast</li></ul> | <ul aria-label="HTML Cons"><li>Hard to scale</li></ul> |
|
||||
| Client Side Rendering (CSR) | <ul aria-label="CSR Pros"><li>Easy to scale</li><li>Ease of engineering</li></ul> | <ul aria-label="CSR Cons"><li>Slow JS initialization</li><li>SEO concerns</li></ul> |
|
||||
| Server Server Render (SSR) | <ul aria-label="SSR Pros"><li>Query based optimization</li><li>Better SEO handling</li><li>Usable without client JS enabled</li></ul> | <ul aria-label="SSR Cons"><li>Heavier server load</li><li>Needs specific server</li><li>More dev effort than CSR</li></ul> |
|
||||
| Compile Time Rendering (SSG) | <ul aria-label="SSG Pros"><li>Layout based optimization</li><li>Better SEO handling</li><li>Usable without client JS enabled</li><li>CDN hostable</li></ul> | <ul aria-label="SSG Cons"><li>No access to query data</li><li>More dev effort than CSR</li></ul> |
|
||||
|
||||
Consider each of these utilities a tool in your toolbox. You may be working on a landing page for a client where SSG would fit best — working on an internal SPA that only has a limited budget allocated to it? Client-side rendering might be your best bet there! Are you working on a public-facing app that highly depends on real-time data? SSR's for you! Each of these has its utility in their problem-space. It's good to keep that in mind when selecting one for your next project.
|
||||
|
||||
In fact, if you're using a framework that supports more than one of these methods ([like NextJS does as-of version 9.3](https://nextjs.org/blog/next-9-3)), knowing which of these utilities to use for which pages can be critical for optimizing your app.
|
||||
|
||||
# A Note Regarding Performance Benchmarks {#lighthouse}
|
||||
|
||||
I was once tasked with migrating a landing page with an associated blog from CSR to use SSG. Once I had done so, however, I noticed that [my Lighthouse score](https://developers.google.com/web/tools/lighthouse) had gone _down_ despite my page rendering a much more useful initial page significantly faster than it'd taken for my app's spinner to go away.
|
||||
|
||||
> "Why did my lighthouse scores go down when using SSG?"
|
||||
|
||||
I wasn't able to find an answer quickly, but eventually, I found out. Lighthouse scores based on many factors. One of those factors is "time until fully loaded." Here's where my problems came into play:
|
||||
|
||||
When doing server-side rendering or static site generation, you're shipped HTML and CSS. Then, to ensure your app fully works and is interactive after the intial load, it will preload the framework you built your site in. Once your framework preloads, it will oftentimes re-render the initial page that was shipped with HTML/CSS. Because the page is both pre-hydrated and responsible for initializing the framework afterwards on the client machine, your benchmarks may potentially suffer, despite the experience being better.
|
||||
|
||||

|
||||
|
||||
> While it's _technically_ possible to do things like [compile React entirely out of an exported NextJS site](https://github.com/zeit/next.js/issues/5054), it's far from trivial and doesn't fit _most_ usage very well. It's certainly a harder mental model at the very least.
|
||||
|
||||
Here's an anecdote that was told to me by [Aaron Frost](https://twitter.com/aaronfrost) (the creator of the SSG utility [Scully](http://scully.io/)) about this scenario:
|
||||
|
||||
> There once was an airport that had low ratings from an audit company that rated an airport's speed and quality. The biggest complaint from the rating was that the time it took to get un-boarded and to the baggage claim was too long. One of the reasons for this was due to how the planes were landing. When the planes landed, they were far away from the baggage claim, forcing their customers to walk a long distance before getting to the baggage claim.
|
||||
>
|
||||
> The airport decided to re-arrange how their planes landed in the future. While the customers seemed to be much happier overall, they received a lower rating on their next audit. This clearly contradicted the claims of their fliers. It turns out that the way the auditor was rating the airport was how much downtime they had before receiving a bag. While the others enjoyed reading articles on their phones during the downtime, the auditor was able to start their timer sooner as a result of walking for a shorter period of time.
|
||||
|
||||
All in all, while lighthouse might score you lower, you can rest assured that your customers will be happier knowing that you have a much more useful interaction on first glance than a site that doesn't use something like SSG.
|
||||
|
||||
# Conclusion
|
||||
|
||||
As mentioned previously, having SSR and SSG in your toolbox are incredibly useful to have at your disposal. While not appropriate for every application, those that are tend to see great advantages from the concepts. Hopefully we've been able to provide a bit of insight that'll spark further learning and research into them.
|
||||
|
||||
|
||||
|
||||
Now you have familiarity with what SSR and SSG are, maybe you want to take a stab at implementing it? [We took a look recently at creating a blog using an Angular SSG solution called Scully](/posts/making-an-angular-blog-with-scully/).
|
||||
|
||||
|
||||
As always, let us know what you think down in the comments below or [in our community Discord](https://discord.gg/FMcvc6T).
|
||||
1
content/blog/what-is-ssr-and-ssg/normal.svg
Normal file
|
After Width: | Height: | Size: 47 KiB |
1
content/blog/what-is-ssr-and-ssg/ssg.svg
Normal file
|
After Width: | Height: | Size: 50 KiB |
1
content/blog/what-is-ssr-and-ssg/ssg_slowdown.svg
Normal file
|
After Width: | Height: | Size: 53 KiB |
1
content/blog/what-is-ssr-and-ssg/ssr.svg
Normal file
|
After Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 9.4 MiB After Width: | Height: | Size: 9.4 MiB |
|
Before Width: | Height: | Size: 181 KiB After Width: | Height: | Size: 181 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 320 KiB After Width: | Height: | Size: 320 KiB |
|
Before Width: | Height: | Size: 179 KiB After Width: | Height: | Size: 179 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 102 KiB After Width: | Height: | Size: 102 KiB |
@@ -40,7 +40,7 @@
|
||||
"github": "evelynhathaway"
|
||||
},
|
||||
"pronouns": "she",
|
||||
"profileImg": "../../content/assets/branding/emotes/proud.png",
|
||||
"profileImg": "../../src/assets/emotes/proud.png",
|
||||
"color": "#ef5f17",
|
||||
"roles": ["developer", "devops"]
|
||||
},
|
||||
|
Before Width: | Height: | Size: 5.7 KiB After Width: | Height: | Size: 5.7 KiB |
@@ -23,7 +23,7 @@ module.exports = {
|
||||
{
|
||||
resolve: `gatsby-source-filesystem`,
|
||||
options: {
|
||||
path: `${__dirname}/content/assets`,
|
||||
path: `${__dirname}/src/assets`,
|
||||
name: `assets`
|
||||
}
|
||||
},
|
||||
@@ -39,7 +39,7 @@ module.exports = {
|
||||
{
|
||||
resolve: `gatsby-source-filesystem`,
|
||||
options: {
|
||||
path: `./src/data`
|
||||
path: `./content/data`
|
||||
}
|
||||
},
|
||||
{
|
||||
@@ -62,7 +62,6 @@ module.exports = {
|
||||
resolve: `gatsby-transformer-remark`,
|
||||
options: {
|
||||
plugins: [
|
||||
`count-inline-code`,
|
||||
{
|
||||
resolve: `gatsby-remark-images`,
|
||||
options: {
|
||||
@@ -118,6 +117,7 @@ module.exports = {
|
||||
]
|
||||
}
|
||||
},
|
||||
`count-inline-code`,
|
||||
`gatsby-transformer-sharp`,
|
||||
`gatsby-plugin-sharp`,
|
||||
{
|
||||
@@ -217,7 +217,7 @@ module.exports = {
|
||||
background_color: `#ffffff`,
|
||||
theme_color: `#127db3`,
|
||||
display: `minimal-ui`,
|
||||
icon: `content/assets/unicorn-utterances-logo-512.png`
|
||||
icon: `src/assets/unicorn_utterances_logo_512.png`
|
||||
}
|
||||
},
|
||||
`gatsby-plugin-offline`,
|
||||
|
||||
2920
package-lock.json
generated
50
package.json
@@ -14,48 +14,47 @@
|
||||
},
|
||||
"lint-staged": {
|
||||
"*.{ts,tsx}": [
|
||||
"npm run format:ts",
|
||||
"git add"
|
||||
"npm run format:ts"
|
||||
],
|
||||
"*.scss": [
|
||||
"npm run format:css",
|
||||
"git add"
|
||||
"npm run format:css"
|
||||
]
|
||||
},
|
||||
"dependencies": {
|
||||
"@textlint/markdown-to-ast": "^6.1.7",
|
||||
"@types/react-paginate": "^6.2.1",
|
||||
"batteries-not-included": "0.0.2",
|
||||
"classnames": "^2.2.6",
|
||||
"css-loader": "^3.4.0",
|
||||
"disqus-react": "^1.0.7",
|
||||
"gatsby": "^2.19.43",
|
||||
"gatsby-image": "^2.2.43",
|
||||
"gatsby-plugin-feed": "^2.3.28",
|
||||
"gatsby-plugin-google-analytics": "^2.1.37",
|
||||
"gatsby": "^2.20.4",
|
||||
"gatsby-image": "^2.3.1",
|
||||
"gatsby-plugin-feed": "^2.4.1",
|
||||
"gatsby-plugin-google-analytics": "^2.2.1",
|
||||
"gatsby-plugin-lunr": "^1.5.2",
|
||||
"gatsby-plugin-manifest": "^2.2.47",
|
||||
"gatsby-plugin-offline": "^3.0.40",
|
||||
"gatsby-plugin-manifest": "^2.3.2",
|
||||
"gatsby-plugin-offline": "^3.1.1",
|
||||
"gatsby-plugin-prefetch-google-fonts": "^1.4.3",
|
||||
"gatsby-plugin-react-helmet": "^3.1.23",
|
||||
"gatsby-plugin-react-helmet": "^3.2.1",
|
||||
"gatsby-plugin-react-svg": "^3.0.0",
|
||||
"gatsby-plugin-robots-txt": "^1.5.0",
|
||||
"gatsby-plugin-sass": "^2.1.30",
|
||||
"gatsby-plugin-sharp": "^2.4.12",
|
||||
"gatsby-plugin-sitemap": "^2.2.29",
|
||||
"gatsby-plugin-sass": "^2.2.1",
|
||||
"gatsby-plugin-sharp": "^2.5.3",
|
||||
"gatsby-plugin-sitemap": "^2.3.1",
|
||||
"gatsby-plugin-transition-link": "^1.18.0",
|
||||
"gatsby-plugin-typescript": "^2.2.3",
|
||||
"gatsby-remark-autolink-headers": "^2.1.25",
|
||||
"gatsby-remark-copy-linked-files": "^2.1.39",
|
||||
"gatsby-plugin-typescript": "^2.3.1",
|
||||
"gatsby-remark-autolink-headers": "^2.2.1",
|
||||
"gatsby-remark-copy-linked-files": "^2.2.1",
|
||||
"gatsby-remark-external-links": "0.0.4",
|
||||
"gatsby-remark-images": "^3.1.49",
|
||||
"gatsby-remark-images": "^3.2.1",
|
||||
"gatsby-remark-images-medium-zoom": "^1.4.0",
|
||||
"gatsby-remark-prismjs": "^3.3.35",
|
||||
"gatsby-remark-responsive-iframe": "^2.2.33",
|
||||
"gatsby-remark-prismjs": "^3.4.1",
|
||||
"gatsby-remark-responsive-iframe": "^2.3.1",
|
||||
"gatsby-remark-video": "^1.2.5",
|
||||
"gatsby-source-filesystem": "^2.1.55",
|
||||
"gatsby-transformer-json": "^2.2.27",
|
||||
"gatsby-transformer-remark": "^2.6.58",
|
||||
"gatsby-transformer-sharp": "^2.3.18",
|
||||
"gatsby-source-filesystem": "^2.2.2",
|
||||
"gatsby-transformer-json": "^2.3.1",
|
||||
"gatsby-transformer-remark": "^2.7.1",
|
||||
"gatsby-transformer-sharp": "^2.4.2",
|
||||
"medium-zoom": "^1.0.5",
|
||||
"node-sass": "^4.13.0",
|
||||
"prismjs": "^1.17.1",
|
||||
@@ -89,7 +88,7 @@
|
||||
"@typescript-eslint/parser": "^2.21.0",
|
||||
"babel-jest": "^25.1.0",
|
||||
"babel-loader": "^8.0.6",
|
||||
"babel-preset-gatsby": "^0.2.35",
|
||||
"babel-preset-gatsby": "^0.3.1",
|
||||
"eslint": "^6.8.0",
|
||||
"eslint-config-prettier": "^6.10.0",
|
||||
"eslint-plugin-prettier": "^3.1.2",
|
||||
@@ -125,6 +124,7 @@
|
||||
"build": "gatsby build",
|
||||
"debug": "gatsby clean && node --nolazy --inspect-brk --max-old-space-size=2000 ./node_modules/gatsby/dist/bin/gatsby.js develop",
|
||||
"develop": "gatsby develop",
|
||||
"debug": "gatsby clean && node --nolazy --inspect-brk --max-old-space-size=2000 ./node_modules/gatsby/dist/bin/gatsby.js develop",
|
||||
"format": "run-s format:**",
|
||||
"format:ts": "eslint --fix ./src/**/*.{ts,tsx}",
|
||||
"format:css": "stylelint --syntax=scss --fix \"./src/**/*.scss\"",
|
||||
|
||||
@@ -1,5 +1,15 @@
|
||||
// I would rather have these in their respective plugins folders, but Gatsby
|
||||
// didn't like having MarkdownRemarkFields implemented twice
|
||||
/**
|
||||
* While I would much MUCH rather utilize the existing AST manipulation from
|
||||
* the remarked plugin, we've hit a bit of a snag. The problem is explained here:
|
||||
* https://github.com/gatsbyjs/gatsby/issues/22287
|
||||
*
|
||||
* Once this issue is resolved/workedaround, we can move back to the code that
|
||||
* was previously confirmed working here:
|
||||
* https://github.com/unicorn-utterances/unicorn-utterances/tree/c6d64a44ee8a4e7d6cad1dbd2d01bc9a6ad78241/plugins/count-inline-code
|
||||
*/
|
||||
const flatFilter = require("unist-util-flat-filter");
|
||||
const parse = require("@textlint/markdown-to-ast").parse;
|
||||
|
||||
exports.createSchemaCustomization = ({ actions }) => {
|
||||
const { createTypes } = actions;
|
||||
const typeDefs = `
|
||||
@@ -15,3 +25,28 @@ exports.createSchemaCustomization = ({ actions }) => {
|
||||
`;
|
||||
createTypes(typeDefs);
|
||||
};
|
||||
exports.sourceNodes = ({ getNodesByType, actions }) => {
|
||||
const postNodes = getNodesByType(`MarkdownRemark`);
|
||||
const { createNodeField } = actions;
|
||||
postNodes.forEach(postNode => {
|
||||
const markdownAST = parse(postNode.rawMarkdownBody);
|
||||
const inlineCodeAST = flatFilter(markdownAST, node => node.type === "Code");
|
||||
let inlineWords = 0;
|
||||
if (inlineCodeAST && inlineCodeAST.children) {
|
||||
inlineWords = inlineCodeAST.children
|
||||
// Prevent grabbing from https://github.com/nullhook/gatsby-remark-video
|
||||
.filter(child => !child.value.startsWith("video:"))
|
||||
.reduce((numberOfInline, inlineCodeNode) => {
|
||||
const { value } = inlineCodeNode;
|
||||
const words = value.split(/\b/g);
|
||||
return numberOfInline + words.length;
|
||||
}, 0);
|
||||
}
|
||||
|
||||
createNodeField({
|
||||
name: `inlineCount`,
|
||||
node: postNode,
|
||||
value: inlineWords
|
||||
});
|
||||
});
|
||||
};
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
const flatFilter = require("unist-util-flat-filter");
|
||||
|
||||
const addInlineCount = ({ markdownAST, actions, markdownNode, ...props }) => {
|
||||
const { createNodeField } = actions;
|
||||
const inlineCodeAST = flatFilter(
|
||||
markdownAST,
|
||||
node => node.type === "inlineCode"
|
||||
);
|
||||
let inlineWords = 0;
|
||||
if (inlineCodeAST && inlineCodeAST.children) {
|
||||
inlineWords = inlineCodeAST.children.reduce(
|
||||
(numberOfInline, inlineCodeNode) => {
|
||||
const { value } = inlineCodeNode;
|
||||
const words = value.split(/\b/g);
|
||||
return numberOfInline + words.length;
|
||||
},
|
||||
0
|
||||
);
|
||||
}
|
||||
|
||||
createNodeField({
|
||||
name: `inlineCount`,
|
||||
node: markdownNode,
|
||||
value: inlineWords
|
||||
});
|
||||
};
|
||||
|
||||
module.exports = addInlineCount;
|
||||
23
plugins/count-inline-code/package-lock.json
generated
@@ -1,23 +0,0 @@
|
||||
{
|
||||
"name": "count-inline-code",
|
||||
"version": "0.0.1",
|
||||
"lockfileVersion": 1,
|
||||
"requires": true,
|
||||
"dependencies": {
|
||||
"unist-util-flat-filter": {
|
||||
"version": "1.0.0",
|
||||
"resolved": "https://registry.npmjs.org/unist-util-flat-filter/-/unist-util-flat-filter-1.0.0.tgz",
|
||||
"integrity": "sha512-zjTmbMgyL1V7iUCnFaGLms9HtGbqK4d3YINqzu+wiMbau93GdiDGtJiB8lMhAyxAaxIAK2rOCeBCldF0FUreKQ==",
|
||||
"requires": {
|
||||
"unist-util-is": "^4.0.0"
|
||||
},
|
||||
"dependencies": {
|
||||
"unist-util-is": {
|
||||
"version": "4.0.1",
|
||||
"resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-4.0.1.tgz",
|
||||
"integrity": "sha512-7NYjErP4LJtkEptPR22wO5RsCPnHZZrop7t2SoQzjvpFedCFer4WW8ujj9GI5DkUX7yVcffXLjoURf6h2QUv6Q=="
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"name": "count-inline-code",
|
||||
"name": "count-inline-code-2",
|
||||
"version": "0.0.1",
|
||||
"description": "",
|
||||
"main": "index.js",
|
||||
|
||||
0
content/assets/branding/emotes/proud.png → src/assets/emotes/proud.png
Executable file → Normal file
|
Before Width: | Height: | Size: 188 KiB After Width: | Height: | Size: 188 KiB |
0
content/assets/hello-2048.png → src/assets/hello_2048.png
Executable file → Normal file
|
Before Width: | Height: | Size: 179 KiB After Width: | Height: | Size: 179 KiB |
0
content/assets/proud-2048.png → src/assets/proud_2048.png
Executable file → Normal file
|
Before Width: | Height: | Size: 180 KiB After Width: | Height: | Size: 180 KiB |
|
Before Width: | Height: | Size: 366 KiB After Width: | Height: | Size: 366 KiB |
|
Before Width: | Height: | Size: 156 KiB After Width: | Height: | Size: 156 KiB |
|
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 39 KiB |
@@ -210,6 +210,39 @@ $pendIconMarg: #{$baseUnit}px;
|
||||
h5 + h6 {
|
||||
margin-top: 0.75em;
|
||||
}
|
||||
|
||||
table tr:last-child th:first-child {
|
||||
border-bottom-left-radius: 10px;
|
||||
}
|
||||
|
||||
table tr:last-child td:first-child {
|
||||
border-bottom-left-radius: 10px;
|
||||
}
|
||||
|
||||
table tr:last-child td:last-child {
|
||||
border-bottom-right-radius: 10px;
|
||||
}
|
||||
|
||||
table {
|
||||
border: var(--cardOutlineStyle);
|
||||
border-radius: var(--cardRadius);
|
||||
border-collapse: collapse;
|
||||
// Border-collapse and border-radius don't mix. This is a workaround for that issue
|
||||
box-shadow: 0 0 0 1px var(--primary);
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
tr,
|
||||
td,
|
||||
th {
|
||||
border: var(--cardOutlineStyle);
|
||||
}
|
||||
|
||||
td,
|
||||
th {
|
||||
padding-left: 1rem;
|
||||
padding-right: 1rem;
|
||||
}
|
||||
}
|
||||
|
||||
.post-lower-area {
|
||||
|
||||
@@ -49,7 +49,7 @@ export const pageQuery = graphql`
|
||||
repoPath
|
||||
}
|
||||
}
|
||||
file(relativePath: { eq: "sad_unicorn-2048.png" }) {
|
||||
file(relativePath: { eq: "sad_unicorn_2048.png" }) {
|
||||
childImageSharp {
|
||||
fixed(width: 500, quality: 100) {
|
||||
...GatsbyImageSharpFixed
|
||||
|
||||
@@ -55,7 +55,7 @@ const AboutUs = (props: any) => {
|
||||
description
|
||||
}
|
||||
}
|
||||
file(relativePath: { eq: "unicorn-head-1024.png" }) {
|
||||
file(relativePath: { eq: "unicorn_head_1024.png" }) {
|
||||
childImageSharp {
|
||||
fixed(width: 192, quality: 100) {
|
||||
...GatsbyImageSharpFixed
|
||||
|
||||
@@ -13,9 +13,12 @@ const Confirm = (props: any) => {
|
||||
style={{
|
||||
margin: "0 auto",
|
||||
display: "block",
|
||||
width: "500px",
|
||||
width: "calc(100vw - 40px)",
|
||||
height: "calc(100vw - 40px)",
|
||||
maxWidth: "450px",
|
||||
maxHeight: "450px",
|
||||
background: "var(--primary)",
|
||||
borderRadius: "50%"
|
||||
borderRadius: "100%"
|
||||
}}
|
||||
loading={"eager"}
|
||||
/>
|
||||
@@ -30,7 +33,7 @@ const Confirm = (props: any) => {
|
||||
|
||||
export const pageQuery = graphql`
|
||||
query ConfirmSiteData {
|
||||
file(relativePath: { eq: "hello-2048.png" }) {
|
||||
file(relativePath: { eq: "hello_2048.png" }) {
|
||||
childImageSharp {
|
||||
fixed(width: 500, quality: 100) {
|
||||
...GatsbyImageSharpFixed
|
||||
|
||||
@@ -13,9 +13,12 @@ const Thanks = (props: any) => {
|
||||
style={{
|
||||
margin: "0 auto",
|
||||
display: "block",
|
||||
width: "500px",
|
||||
width: "calc(100vw - 40px)",
|
||||
height: "calc(100vw - 40px)",
|
||||
maxWidth: "450px",
|
||||
maxHeight: "450px",
|
||||
background: "var(--primary)",
|
||||
borderRadius: "50%"
|
||||
borderRadius: "100%"
|
||||
}}
|
||||
loading={"eager"}
|
||||
/>
|
||||
@@ -30,7 +33,7 @@ const Thanks = (props: any) => {
|
||||
|
||||
export const pageQuery = graphql`
|
||||
query ThanksSiteData {
|
||||
file(relativePath: { eq: "proud-2048.png" }) {
|
||||
file(relativePath: { eq: "proud_2048.png" }) {
|
||||
childImageSharp {
|
||||
fixed(width: 500, quality: 100) {
|
||||
...GatsbyImageSharpFixed
|
||||
|
||||
@@ -19,6 +19,8 @@ const BlogPostTemplateChild = (props: BlogPostTemplateProps) => {
|
||||
const siteData = props.data.site.siteMetadata;
|
||||
const slug = post.fields.slug;
|
||||
|
||||
console.log(post.fields);
|
||||
|
||||
const { currentTheme } = useContext(ThemeContext);
|
||||
|
||||
const [disqusConfig, setDisqusConfig] = useState({
|
||||
|
||||
@@ -35,6 +35,8 @@ const BlogProfile = (props: BlogProfileProps) => {
|
||||
const unicornData = slugData.unicornsJson;
|
||||
const posts = slugData.allMarkdownRemark.edges;
|
||||
|
||||
debugger;
|
||||
|
||||
const wordCount = useMemo(() => {
|
||||
return posts.reduce(
|
||||
(prev, post) =>
|
||||
|
||||
@@ -95,7 +95,7 @@ export const pageQuery = graphql`
|
||||
}
|
||||
}
|
||||
}
|
||||
file(relativePath: { eq: "unicorn-utterances-logo-512.png" }) {
|
||||
file(relativePath: { eq: "unicorn_utterances_logo_512.png" }) {
|
||||
childImageSharp {
|
||||
fixed(width: 300, quality: 100) {
|
||||
...GatsbyImageSharpFixed
|
||||
|
||||