metadata - freeCodeCamp.org

How to Configure Metadata for a Single-Page Application

freeCodeCamp — Tue, 20 Sep 2022 17:20:15 +0000

By Scott Gary

Why Metadata Matters

Metadata is an integral part of any modern web app, because it's inherently tethered to search engine optimization (SEO).

Search engines and their respective results page (SERPS) rely on metadata to properly index and display relative information for each site.

Also, meta tags are relied upon to properly display content from your site on a given social media platform, such as articles or items for sale.

For this reason, it's crucial to understand how metadata is configured in a modern web app.

The single page application (SPA) is a modern web app implementation that is incredibly popular. Most frameworks today utilize it in some way. Configuring metadata in today’s most popular SPA frameworks will be the focus of this tutorial.

The Single Page Application and Metadata

The nature of SPAs make configuring metadata a less straightforward process than classic multiple page applications. I'm going to try to clarify this topic by describing the following key concepts:

The structure of an SPA.
The problem with modifying metadata in an SPA.
Available metadata solutions using what are probably the three most popular SPA frameworks: React, Svelte, and Vue.

You should have a basic understanding of HTML, metadata, and one of the three SPA frameworks to understand the concepts we’ll be going over. But, I’ll be keeping things beginner friendly, so don’t worry!

How Single Page Applications Work

Before diving in, you need a firm grasp of what constitutes an SPA.

As the name implies, a single page application literally consists of a single HTML page sent down from the server. This page is just an empty HTML shell, and will look something like this:

html>
    <html>
        <head>
        <title>Home | Demystifying SPA Metadatatitle>
        <meta name="description" content="How to configure popular SPA             frameworks to maintain quality site metadata."/>
        <link rel="stylesheet" href="./stylesheet.css" type="text/css"             />
        head>
        <body>
            <script src="/bundle.min.js" type="text/javascript">                    script>
        body>
    html>

You might be wondering how an entire website is derived from this empty HTML shell.

This is possible because along with the HTML page will be extensive client-side JavaScript code that generates the content for each page. This code is included in the page via the

Creating a Custom React Hook for Gatsby Site Metadata

freeCodeCamp — Sun, 24 Mar 2019 17:14:00 +0000

By Scott Spence

Hooks ahoy!

Ok, let's get it on with the new hotness in Reactland, React Hooks!
This is a guide covering using the Gatsby custom React hook for
StaticQuery which it is now replacing with useStaticQuery.

If you haven't used Gatsby before StaticQuery is just that, a way to
query data in a Gatsby component (i.e. a react component) or a Gatsby
page where the query input doesn't change. This is a great use case
for data that doesn't change a great deal, like your site metadata.

tl;dr

Here's me trying to even with codesandbox.io whilst I convert some
of the Gatsby default starter that's on codesandbox.io to use the
useSiteMetadata custom hook.

Using codesandbox.io we take a look at implementing a custom react
hook for getting site metadata in Gatsby.

Here's a video:

The StaticQuery component uses the render props pattern, which
means it takes in a function and returns/renders based off of that.

I have detailed this pattern before in a post about using the react
context api, it's a component that you pass a function to, to render
a component.

Think of it like this:


 {() => ()}

The first parenthesis is the arguments/variables and the second is
what gets rendered, so in the case of the Gatsby StaticQuery you
pass a query with a graphql tag and then the data that comes back
from that is what is used in the render of that component. So you have
your wrapping component that returns and renders a child component,
like this.


  {args => <ComponentToRender propsForComponent={args.propNeeded} />}

Here's a cut down version of the StaticQuery component being used in
the Gatsby default starter on codesandbox.io

I've taken out the styling to make it a bit shorter:

const Layout = ({ children }) => (
  <StaticQuery
    query={graphql`
      query SiteTitleQuery {
        site {
          siteMetadata {
            title
          }
        }
      }
    `}
    render={data => (
      <>
        <Header siteTitle={data.site.siteMetadata.title} />
        <div>
          <main>{children}main>
          <footer />
        div>
      
    )}
  />
);

export default Layout;

The StaticQuery takes in two props, the query and what you want to
render with render, this is where you can destructure the data you
need out of the data prop returned from the query.

I was never really a fan of doing it that way so I adopted a similar
pattern but with the component contained on it's own and then added to
the StaticQuery separately. Like this:

const Layout = ({ children, data }) => (
  <>
    <Header siteTitle={data.site.siteMetadata.title} />
    <div>
      <main>{children}main>
      <footer />
    div>
  
);

export default props => (
  <StaticQuery
    query={graphql`
      query SiteTitleQuery {
        site {
          siteMetadata {
            title
          }
        }
      }
    `}
    render={data => <Layout data={data} {...props} />}
  />
);

I found this more acceptable because you didn't have to have all the
code bunched into the StaticQuery component.

That all make sense?

Good, now forget about all of that! It's time to use the new
useStaticQuery hotness in Gatsby. ?

Versions:

This guide is being used with the following dependency versions.

gatsby: 2.1.31
react: 16.8.4
react-dom: 16.8.4

You can also check out the example code.

The Gatsby documentation covers the use of it and also how to make
your own custom react hook to use useStaticQuery, here's the one I
use in the video.

useSiteMetadata.js

import { graphql, useStaticQuery } from 'gatsby';

const useSiteMetadata = () => {
  const { site } = useStaticQuery(
    graphql`
      query SITE_METADATA_QUERY {
        site {
          siteMetadata {
            title
            description
            author
          }
        }
      }
    `
  );
  return site.siteMetadata;
};

export default useSiteMetadata;

This can now be implemented in the rest of the code as a function
call:

const { title, description, author } = useSiteMetadata();

Let's implement it!

In the layout component import the useSiteMetadata hook then we
can go about removing the StaticQuery component and destructuring
title from the useSiteMetadata hook.

It should look something like this, I have taken the styling out for
brevity:

import React from 'react';
import PropTypes from 'prop-types';
import useSiteMetadata from './useSiteMetadata';

import Header from './header';
import './layout.css';

const Layout = ({ children }) => {
  const { title } = useSiteMetadata();
  return (
    <>
      <Header siteTitle={title} />
      <div>
        <main>{children}main>
        <footer>
          © {new Date().getFullYear()}, Built with
          {` `}
          <a href="https://www.gatsbyjs.org">Gatsbya>
        footer>
      div>
    
  );
};
Layout.propTypes = {
  children: PropTypes.node.isRequired,
};

export default Layout;

Here's the comparison:

On now to the seo component, same again, remove StaticQuery and
use useSiteMetadata in it's place.

Here's the comparison:

If you want to check out the code the example is available here:
example code

Wrap up!

That's it! Wh have gone from using the awesome StaticQuery render
props pattern used in Gatsby over to the even more awesome
useStaticQuery React hooks, hook.

Thanks for reading ?

Please take a look at my other content if you enjoyed this.

Follow me on Twitter or Ask Me Anything on GitHub.

You can read other articles like this on my blog.

Normal Forms aren’t just for databases

freeCodeCamp — Sun, 08 Jul 2018 22:48:15 +0000

By Jeff M Lowery

You can apply similar rules to data object types, too.

You probably learned the term Normal Form in the context of defining schemas for relational databases. Database normalization strives to reduce data redundancy in table rows and columns. Consequently, data anomalies are less likely to occur.

What’s a data anomaly?

Suppose we had this situation:

Table A contains values for properties X, Y, Z for a row identified by the id of x; these are assertions about x. Let’s say Y in row x is asserted to be the value 3.

Table B also contains the same assertions about why Y for x

Table A is told later, “Facts have changed. Y is now 4”

Table B is later queried, and says Y is still 3.

Now A and B assert two different facts about Y, depending on which table you query.

That’s a data anomaly: two different assertions about a fact. And facts do matter in computer systems.

The what and whyfors of Normal Forms

I’ll use the term type to denote the meta data of an object. This could be implemented by a class definition, mixin, trait, stamp, or whatever mechanism your preference and language of choice supports. I’ll also be focusing on data objects, such as POJOs, PODOs, JSON and similar simple objects.

Stated informally, the first three normal forms are described as follows:

First Normal Form (1NF): No repeating elements or groups of elements

Second Normal Form (2NF): All Non-key Attributes are Dependent on All of Key

Third Normal Form (3NF): No dependencies on non-key attributes

That’s pretty dry reading. But applying these principles to object type definitions is actually pretty intuitive. Once you’ve internalized these rules, you won’t even think about them consciously again.

Objects are relational, too

Relational databases support associations by way of Primary and Foreign Key constraints. Hierarchies are implicit, if they exist at all. Associations are looser than hierarchies and taxonomies, but also harder to think about.

In a hierarchy, you have parent-child relationships. There is often a hierarchy of data types as well (class-subclass) which is also modeled. Relationships in a object containment hierarchy are more constrained, generally one-way (parent to child), but also easier to grasp than a more general (and flexible) association.

1NF: No repeating elements or groups of elements

Say we have the following contact information:

Where are the repeating elements?

Name attributes: this could be considered a one-to-many relationship, where the number of names is indeterminate (such as British royalty). In practice, though, first, last, and possibly middle name are sufficient for most application domains, so there’s no real need to normalize these fields.
phones: The repetition of phone attributes does look like a potential problem: is two phones enough? And what if further information is later associated with the phone number, like time available?
address lines: again, are two enough? In some countries, street addresses can be four lines long, but that’s the limit. Since they are simple strings, it’s no tragedy if one or two more address lines are added later.

Here’s a possible model, with Contact and Phone types:

2NF: All Non-key Attributes are Dependent on All of Key

What does this mean in plain English? In a database, it means that all columns in a row should be directly dependent on any candidate keys of that row.

So let’s take a look at Contact again:

Here the key is a generated id value, sometimes referred to as a surrogate key. Are the address attributes dependent on Contact ID? Well…

It all depends on the domain.

The six address properties are surely not attributes of the Contact, but are rather means of identifying a physical location. It is possible a contact could have many addresses, and perhaps an address has many contacts.

Should this be modeled as a many-to-many relationship, with some ContactAddress object type that has a Contact ID and an Address ID? It is going to depend on what is important to your application domain. Some application may treat Contacts as strong entities, independent of Address, but Addresses as weak entities, dependent on a Contact for existence. In that case, one contact can have many addresses, and each address refers to a contact, like this:

There is a potential data anomaly: if you change the address for one contact, you don’t change that same address for all contacts. If Contact is your primary source of reference, then that may be the desired behavior: your contact moves (to another organization, say) and the remaining Contacts stay in place.

3NF: No dependencies on non-key attributes

Looking at Address again, you might spot the two dependent fields, region and country. A country may or may not have regions, but a region does have a country: you don’t want to mix them up.

One way of ensuring that the region belongs to the correct country is to create an identifier for each (country, region) pair, then have the address refer to the identifier rather than to region and country independently:

A word about generated identifiers

In my opinion, generated identifiers are an implementation detail, and are really only needed by client code when modifying or deleting a back-end record (such as a row in a database), but never as part of a read-only query. They should also never be seen by the user of the system, because they are meaningless.

Table per Type, Table per Type Hierarchy

The neat thing about normalized object types is that they map easily to relational database tables. For a relational database implementation, tables mirror the object types (Table per Type) or at least contain information for multiple types derived from a base type (Table per Type Hierarchy). This may sound like I’m advocating Object-Relational Mapping, but no… I am merely saying that it is beneficial to have your Logical Model share the same characteristics of the Physical Model at a conceptual level. Implementation is another subject entirely.

References

There are ample resources about normalization of relation database schemas:

Database Normalization: First, Second, and Third Normal Forms - Andrew Rollins
I read a great explanation of first, second, and third normal form a few weeks ago. For those that know what database…
www.andrewrollins.com

Database Second Normal Form Explained in Simple English
The second post focused on the first normal form , its definition, and examples to hammer it home. Now it is time to…
www.essentialsql.com

What is Second Normal Form (2NF)? - Definition from Techopedia
Second Normal Form 2NF Definition - Second normal form (2NF) is the second step in normalizing a database. 2NF builds…
www.techopedia.com

Database Third Normal Form Explained in Simple English
The third post focused on the second normal form, its definition, and examples to hammer it home. Once a table is in…
www.essentialsql.com

Also, when researching this post, I came across a somewhat different take on how to apply normalization rules to object types.

Introduction to Class Normalization
www.agiledata.org