jondashkyle / nanocontent Goto Github PK

View Code? Open in Web Editor NEW

80.0 6.0 11.0 1.5 MB

read directories of content into an object

JavaScript 100.00%

nanocontent's Introduction

nanocontent

work in progress...

Introducing flat content state. Read directories of content into an object.

Store all of your content in a directory
Each directory is a page
The content for each page is stored in a text file
Your file system becomes a router!
Pairs nicely with nanopage for traversing object structure

npm install nanocontent --save

Usage

Format some plain text files using smarkt fields.

title: Technopastoral
----
date: January 19, 2038
----
tags:
  - garden
  - engineering
----
text: To deprogram oneself necessitates keeping to very specific schedules, which are what Foucault, once again, described as techniques of the self, echoing Seneca.

Organize them within a directory structure alongside media assets.

/content
  /about
    index.txt
  /blog
    /38-01-19-technopastoral
      index.txt
      header.jpg
  index.txt

Turn the directory into an object.

var nanocontent = require('nanocontent')
var site = nanocontent.readSiteSync('./content')

Each directory becomes a path containing a sub-object of the content in your text file.

{
  '/': { },
  '/about': { },
  '/blog': { },
  '/blog/30-01-19-technopastoral': { }
}

Map over the object keys to add routes to a router, then pass the content object. Huzzah.

API

`.readFile(path, [options])`

`.readFiles(files, pathSite, [options])`

`.readPage(path, [options])`

`.readSite(path, [options])`

`.readFileSync(path, [options])`

`.readFilesSync(files, pathSite, [options])`

`.readPageSync(path, [options])`

`.readSiteSync(path, [options])`

Options

`fs`

Provide a custom implementation of fs. Ensure the mkdir readdir writeFile and readFile methods are available. This is useful for replacing Node’s fs with Dat’s API, for instance.

`parse`

Substitute smarkt with your own parser. Must be able to transform a plain text file into a JSON object.

`parent`

Remove part of the url for pretty printing. For example, if your content lives in /content, but you don’t want to prefix all of your urls with /content, use parent to clean it up. Value can be a string or boolean. If true, the path of your initial call is used.

Transform

browserify -t nanocontent/transform

A browserify transform located at nanocontent/transform is included to staticly inline the module output.

Example

A demo site is included. Open the nanocontent/example dir and npm install. The example uses Bankai. Run npm start to spin up a Bankai server and mess around. Run bankai build to build a fully static site.

Todo

Tests
Async callback/promise fallback
Modularize read function for JSON/Smarkt/Custom

nanocontent's People

Contributors

Stargazers

Watchers

Forkers

lachenmayer bendik joehand the-cc-dev repohoarder robinscholz mroberts1 hugmatj

nanocontent's Issues

ReferenceError: regeneratorRuntime is not defined

Trying to use this straight on top of a fresh choo app to build a simple site. However I get ReferenceError: regeneratorRuntime is not defined.

Using @babel/polyfill solves this but throws a fs is not defined error instead. Would be great to get some advice from someone more experienced on this. Thank you.

Transforms?

Would you be open to a rewrite of nanocontent that supported arbitrary transforms (similar to sheetify)?

Feature requests such as #10 suggest that there are diverging needs between nanocontent as an in-browser content wrangler and a static site generator. Transforms could help keep the core of nanocontent simple and well-tested while encouraging others to add custom functionality on their own via custom transforms.

(Additionally, adding a custom parser is currently incompatible with using nanocontent/transform.) WDYT? (cc @jongacnik)

Ignore parent directory

You usually place your content in a sub-directory of your project. For instance:

/project
  /assets
  /content
    /about
      - index.txt
    - index.txt
  /src

Because of this, you don’t want /content to appear in the path for each of your pages. You can currently get around this by passing a parent option.

hypha.readSiteSync('./content', {
  parent: '/content'
})

This is fine, however I can’t think of a case where you’d want to ignore anything other than the name of the parent directory, so this should likely just be a bool instead of a str. Alternatively, could accept both values.

readSite does not work with alternate fs implementations

const archive = new DatArchive('dat://enoki.site/')
const site = await hypha.readSite('content/', { fs: archive })

fails in Beaker with:

index.js:2784 Uncaught (in promise) TypeError: fs.readdir is not a function
    at Glob._readdir (index.js:2784)
    at Glob._processGlobStar (index.js:2862)
    at Glob._process (index.js:2600)
    at new Glob (index.js:2407)
    at glob (index.js:2312)
    at P (index.js:28455)
    at Promise (<anonymous>)
    at index.js:28417
    at ret (index.js:28478)
    at Object.readSite (index.js:20362)

That's because glob does not support custom fs implementations, ie. it just requires fs straight up. There's a PR from 2016(!!!) (isaacs/node-glob#285) to allow custom fs to be passed in to glob, but it hasn't been merged and it looks like it's not going to be updated any time soon.

Considering that the glob is literally just **/*, we could use something like recursive-readdir instead. This also does not allow passing in fs, but the chances of adding that looks straightforward & much more likely to be merged.

Alternatively, we could just write our own implementation based on recursive-readdir, don't think that's a good idea but it would be forward progress...

Update URL key

Currently there are url, path and source keys.

url: the formatted path (removes the parent content dir)
path: the unformatted path of the true location (includes the parent content dir)
source: used for remote content like https://example.com/

This should be updated to conform to Content State Schema.

url: for pages this is formatted, for files this is unformatted
source: used to define a remote location, makes it possible for other modules to fetch state

{
  '/about': {
    url: '/about'
  },
  'about/example.jpg': {
    url: '/content/about/example.jpg'
  }
}

Custom format parsing

Add an option called parser which accepts a function. This is used to transform the plain text into an object. Allows a custom taxonomy.

Accept relative URLs and gblobs

Could be quite nice if the page() and file() constructors accept relative URLs by utilizing path.resolve(). Additionally, we could use globs to construct a new object of pages and files.

var parent = page('../').value('title')
var videos = page('**/*.mp4').toArray()

This is really taking advantage of using paths as keys.

Uncaught TypeError: fs.readdirSync is not a function

Calling var site = nanocontent.readSiteSync('./content') gives error:

Uncaught TypeError: fs.readdirSync is not a function
    at GlobSync._readdir (sync.js:288)
    at GlobSync._processGlobStar (sync.js:350)
    at GlobSync._process (sync.js:130)
    at new GlobSync (sync.js:4)
    at Function.globSync [as sync] (sync.js:26)
    at Object.readSiteSync (readSiteSync.js:19)
    at Object.readSiteSync (index.js:55)

in the glob module.

jondashkyle / nanocontent Goto Github PK

nanocontent's Introduction

nanocontent

Usage

API

.readFile(path, [options])

.readFiles(files, pathSite, [options])

.readPage(path, [options])

.readSite(path, [options])

.readFileSync(path, [options])

.readFilesSync(files, pathSite, [options])

.readPageSync(path, [options])

.readSiteSync(path, [options])