Closed jondashkyle closed 6 years ago
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
?
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.
I was thinking of the split files
and content
objects too as a way to potentially avoid what @s3ththompson https://github.com/jondashkyle/nanopage/issues/9#issuecomment-384449116 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.
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.
This has been implemented in the dev
branch: https://github.com/jondashkyle/nanopage/pull/14
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 flatstate.content
object. what if we did the same forfiles
? in this case, you could havestate.content
which looks like this:started thinking about this when i implemented the updated
find
utility, which does this and would nicely work with passing filenames:should likely update the
pages
regex to ensure there is no extension. likewise, should updatefiles
to look more likepages
, but ensure there is an extension. also, perhaps we could pass an argument into thepages
andfiles
utils which returns a glob of children.this way we could dynamically add pages to a router without a bunch of rogue files ended up in there:
might be getting a little obscure with that router example.