Files

[jondashkyle]

here’s a trip. consider how nanopage referenced pages with a nested object. that was removed and now there is a simple regex against the flat state.content object. what if we did the same for files? in this case, you could have state.content which looks like this:

{
  '/': {
    title: 'Index'
   },
  '/example.jpg': {
    name: 'example',
    extension: 'jpg'
  }
}

started thinking about this when i implemented the updated find utility, which does this and would nicely work with passing filenames:

// updated find utility
if (typeof value.url === 'string') {
    return state.content[resolve(value.url, url)]
}

// example usage
page().find('test.jpg').v()

should likely update the pages regex to ensure there is no extension. likewise, should update files to look more like pages, but ensure there is an extension. also, perhaps we could pass an argument into the pages and files utils which returns a glob of children.

page('/example').pages(true).v()
// returns /example/one, /example/two, /example/two/child, etc…

this way we could dynamically add pages to a router without a bunch of rogue files ended up in there:

// choo router example
page('/').pages(true).keys().forEach(href => app.route(href, view(state, emitter.emit))

// want all your files?
page('/').files(true).v()

might be getting a little obscure with that router example.

[jongacnik]

Top level files is interesting, as is the ability to access recursive children (I had it working like this initially with the regex). So the thinking here is files would be stored with their full path?

{
  '/some/nested/page/file.jpg': {},
  '/another/nested/page/file.jpg': {}
}

Being able to easily access every file is cool. Eventually we could maybe even expose some sort of top level file() helper, like page():

var myFile = file('/some/nested/page/file.jpg')

The router example is funny - is there a reason you would ever register every route like that and not just use :params?

[jondashkyle]

yeah, stored as their full path. the file method is interesting too. you’d prob never do that router example, but i was trying to think of an instance where you would want more of a glob of every page.

another possibility is state.files in addition to state.content, but perhaps the consistency of a single flat object for all content (files included) is most understandable.

[jongacnik]

I was thinking of the split files and content objects too as a way to potentially avoid what @s3ththompson #9 (comment) was mentioning (ballooning content object). My internal dialogue was like: "by introducing everything in the same flat object are we going to run into possible perf issues when querying pages?" but then thought "maybe, but likely negligible, unless you have like thousands of pages and files, but then like, maybe you should be structuring things differently."

I do think devising some patterns/best-practice for progressively loading content is something to consider. For example, in a current build I do something like this, where the initial request serves the necessary page and then shells of everything else. If we were to hit the site from the homepage, window.initialState.content looks something like:

{
  '/': {
    'title': 'My Name',
    'url': '/',
    'text': 'Beep boop.',
    'files': {},
    '_loaded': true
  },
  '/projects': {
    'title': 'Projects'
  },
  '/projects/a': {
    'title': 'Project A'
  },
  '/projects/b': {
    'title': 'Project B'
  },
  '/projects/c': {
    'title': 'Project C'
  },
  '/about': {
    'title': 'About'
  }
}

Then as you move around the site data is loaded in. By loading at the very least all keys you get ability to query for children and etc.

[jondashkyle]

oh interesting @jongacnik , yeah… i dunno if the performance thing is actually an issue for the scale of projects nanopage is engaging. but yeah—if we were to use a files object, we should probably change from using content to pages for clarity, as content no longer contains all your actual content.

[jondashkyle]

This has been implemented in the dev branch: #14