5.0.4 • Published 19 days ago

@jeromefitz/notion v5.0.4

Weekly downloads
-
License
MIT
Repository
github
Last release
19 days ago

🚧️ 🚧️ 🚧️ @jeromefitz/notion 🚧️ 🚧️ 🚧️

Wrapper stuff for jeromefitzgerald.com.

📝️ Please Note:

  • 🧐 Very specific to an implementation I re-use a lot
  • 😬 Lots of any types (currently)
  • 🤔️ Would be good to build this out to be more generic

This is really a custom thing, so not sure how useful this would be for anyone else.

This will not be ready for production/OSS use until 3.0.0 at the earliest. I would imagine all attempts at documentation will wildy fluctuate.

Overview

Notion + Next.js + swr

The concept is kind of mapping databases from Notion to routeTypes in Next being kept in-sync post build via swr.

You will need a few values set up in Notion and identified in a configuration file within your repo provided to this package. (And by few, this is an understatement. Good news! You can create all the values dynamically, howver, that is outside of this package currently.)

Quick

This API extends @notionhq/client so you will extend this one instead.

import { Client } from '@jeromefitz/notion'

import { notionConfig as config } from '~config/websites'

const notion = new Client({ auth: process.env.NOTION_API_KEY, config })

You need to pass config which informs the package of all the wonderful Notion stuff you have. Will fill this out as I go (I hope haha).

(alias) const notionConfig: {
    DATABASES: Databases;
    NOTION: DatabaseInfo;
    PAGES__HOMEPAGE: string;
    PAGES: string[];
    ROUTE_META: any[];
    ROUTE_TYPES_BY_DATA_TYPES: Object;
    ROUTE_TYPES: any[];
}
  • DATABASES: 🔑️ is uppercase (usually gripped by routeType)
  • NOTION: 🔑️ is uppercase; 🛠️ configuration for DB
    • active: boolean
    • database_id: string
    • dataTypes: DataTypes[]
    • hasChild: string | null
    • infoType: any | null
    • isChild: string | null
    • isChildInfoType: any | null
    • name: string
    • page_id__seo: string
    • routeMeta: boolean
    • routeType: string
    • slug: string
    • ttl: number
  • PAGES__HOMEPAGE: 🤕️ what Pages => slug is the homepage?
  • PAGES: 🤕️ Only active routeTypes brought back
  • ROUTE_META: 🤕️ up front share if we expect the route to have a meta (BLOG|EVENTS|PODCASTS)
  • ROUTE_TYPES_BY_DATA_TYPES: For each DATA_TYPE determine which routeType are associated
  • ROUTE_TYPES: 🤕️ Only active routeTypes brought back

Next

Will add an ./examples/next/... to show this with a public facing Notion at some point.

Custom setup to get pathVariables from next:

[...catchAll]:

export const getStaticProps = async ({ preview = false, ...props }) => {
  const { catchAll } = props.params
  // @todo(next)
  const clear = false
  const pathVariables = notion.custom.getPathVariables({ catchAll })
  /**
   * @cache
   * - pages = TRUE
   * - pages/api = FALSE
   */
  const cache = true
  const data = await getDataReturn({
    data: await getCatchAll({
      cache,
      catchAll,
      clear,
      pathVariables,
      preview,
    }),
    pathVariables,
  })
  return {
    props: { preview, ...data, ...pathVariables, ...props },
    revalidate,
  }
}

export const getStaticPaths = () => {
  return getStaticPathsCatchAll()
}

getCatchAll.ts:

  • Checks against cache
  • Based on the dataType from getPathVariables calls notion.dataTypes
  • Sets data
  • Checks if should use plaiceholder to generate images
  • Creates cache if it should
  • Send back

getStaticPathsCatchAll.ts:

  • Create paths via hard-coded values from configuration for:
    • PAGES__HOMEPAGE => index.ts
    • PAGES => Until we can get a proper query to dynamically generate
  • Create paths to generate via next based off of NOTION[#__database__#].databaseTypes:
    • LISTING
    • LISTING_BY_DATE
    • SLUG
    • SLUG_BY_ROUTE
  • Customizations for date based routing for:
    • blog => ./blog/yyyy/mm/dd/blog-title
    • events => ./events/yyyy/mm/dd/events-title
    • episodes => ./podcasts/#__podcast-title__#/#__episode-title#

Cache

Currently set to json files within next build. This (currently) causes it to be generated every build.

For larger datasets this should move to a Key/Value Store that takes into account lastEdited from Notion for anything since the last build. (Or someting like that.)

Why

Next and Notion are awesome.

Before @notionhq/client this was really hacky (cough actually more than this, haha). And now that the API is public, figured I would move this out to keep myself honest and find ways to continually improve it since I had this as a private repo with no documentation (hence a lot of any types and a lack of a formal or even informal README).

5.0.4

19 days ago

5.0.3

1 month ago

5.0.2

2 months ago

5.0.1

3 months ago

5.0.0-canary.2

3 months ago

5.0.0

3 months ago

5.0.0-canary.1

4 months ago

4.0.7

10 months ago

4.0.6

10 months ago

4.0.5

1 year ago

4.0.4

1 year ago

4.0.3

1 year ago

4.0.2

1 year ago

3.3.9

2 years ago

3.3.8

2 years ago

4.0.1

2 years ago

4.0.0

2 years ago

3.3.7

2 years ago

3.3.6

2 years ago

3.3.6-notion-2.1

2 years ago

3.3.5

2 years ago

3.3.0-canary.1

2 years ago

3.3.0-canary.2

2 years ago

3.3.1

2 years ago

3.3.0

2 years ago

3.3.4

2 years ago

3.3.3

2 years ago

3.3.2

2 years ago

3.2.1

2 years ago

3.2.0

2 years ago

3.2.0-canary.2

2 years ago

3.2.0-canary.1

2 years ago

3.1.3

2 years ago

3.1.2

2 years ago

3.1.1

2 years ago

3.1.0

2 years ago

3.1.4

2 years ago

3.0.4

2 years ago

3.0.3

2 years ago

3.0.2

2 years ago

3.0.6

2 years ago

3.0.5

2 years ago

3.0.1

2 years ago

3.0.0

2 years ago

2.0.7

2 years ago

2.0.6

2 years ago

2.0.5

2 years ago

2.0.4

2 years ago

2.0.3

2 years ago

2.0.2

2 years ago

2.0.1

2 years ago

2.0.0

2 years ago

2.0.0-npm-dist.1

2 years ago

1.0.0

2 years ago

1.0.0-notion.8

2 years ago

1.0.0-notion.7

2 years ago

1.0.0-notion.6

2 years ago

1.0.0-notion.5

2 years ago

1.0.0-notion.4

2 years ago

1.0.0-notion.3

2 years ago

1.0.0-notion.2

2 years ago

1.0.0-notion.1

2 years ago