|
|
|
|
|
|
by tomduncalf
2079 days ago
|
|
|
I migrated a couple of sites I look after from react-static (which is a nice, simple library but unfortunately had some fundamental issues that it sounded like we’re unlikely to be solved and gave the impression that it was struggling for maintainers e.g. https://github.com/react-static/react-static/issues/1203), one to Gatsby and the other to NextJS. I agree largely with the findings described here - Gatsby felt quite slow and the GraphQL part feels like complexity overkill, for my use case I bypassed it using their createPage API but you lose out on eg the ability to reload a page’s data on the fly by doing so (from what I could work out - the documentation was a bit lacking in parts I found). I was more impressed with NextJS, it feels generally more solid and easier to understand. It has a great preview feature where you can set a cookie and then the site will pull in data at request time rather than from the static site (perfect for CMS previews!) and build times seem alright - I haven’t had cause to look into speeding them up, which is a good sign. Personally I’d go with NextJS in future based on my experience... that said, I’ve no idea if it would work well for their reasonably specialised use case! |
|
|
I also just figured out how to trigger hot reloading for sources that normally don’t trigger it (markdown files which I was manually processing).
Basically, I discovered that gatsby will hot-reload when it sees a change in code files (.tsx). So I created an essentially empty _rebuild-trigger.tsx file and imported that in my main page template.
Now, to change the page content and trigger a hot-reload:
- I have an observable subscribed in createPagesStateful that calls deletePage and createPage - Then write to the file _rebuild-trigger.tsx file
I need to make a blog post because it works great (and I could tie it to any change source - like file system watcher - during development).