App-Shell based architecture with dynamic loading of required components
Styled components
Recompose
Jest & Enzyme for testing
Storybook
sanitize.css
basscss
basic admin functionality via alanning:roles
Code splitting on startup and router level
Progressive Web App features
The kit is based on the excellent work done by excellent work done by Federico Rodes, however it’s since been heavily modified to provide a more recent base as well as server-side rendering.
I’m happy to have other people propose changes and improvements to try to keep this starter kit up-to-date with updates to Apollo and Meteor.
UPDATE:
I’ve just released a huge update in order to add Multilingual support. It’s best to think about internationalisation from the start of project, so it’s now included in the kit. I’ve updated this pose to reflect that.
Great work! Would also be great if one could submit an issue to that repo.
With regards to service worker and saving to homescreen, I’m looking to pull just that bit out of the repo for an existing app that doesn’t use SSR.
I see this in the code regarding the route:
// /app-shell is a special route that does no server-side rendering
// It's used by the service worker for all navigation routes, so after the first visit
// the initial server response is very quick to display the app shell, and the client
// adds in the data.
// In the case of a first visit or a robot, we render everything on the server.
if (sink.request.url.path === '/app-shell') {
sink.appendToBody(`<script>window.__APOLLO_STATE__=${JSON.stringify(ssrClient.extract())};</script>`);
sink.appendToBody(MeteorLoadable.getLoadedModulesScriptTag());
return;
}
The ssr.js (and the corresponding import) can just be removed if you don’t need SSR. You should also remove these lines from the service worker:
// Cache the App Shell route. We try to get latest from the network, fall back to cache for offline.
workbox.precaching.precache([APP_SHELL]);
workbox.routing.registerRoute(APP_SHELL, new workbox.strategies.StaleWhileRevalidate());
// Our App Shell, used by all navigation routes.
workbox.routing.registerNavigationRoute(APP_SHELL);
I’ve come to dislike redux + meteor for state and data management. It works fine, but lots of overhead. Apollo seemed good in that regard.
Styled component was the last library I tried for CSS, and I love it.
App-Shell based architecture fits perfectly my use case, I was intending to add the dynamic loading soon.
PWA, SSR, all good stuff.
How easy would it be to remove some of the features/packages, like alanning:roles and authentication ? I’ll check for myself in a few days - I might use your starter kit for my project - but I know these 2 will have to go.
I’ve cloned the app, followed the instructions and started the meteor app. It opens and I can login, but the “new version” alert shows up every time until I click “cancel”. If I refresh, it shows up again.
This sounds like a problem between the service worker and Meteor’s auto-refresh. If you can track it down that’d be great. If not, try removing the service worker registration for the time being, by removing this line:
I’ve just released a huge update in order to add Multilingual support. It’s best to think about internationalisation from the start of project, so it’s now included in the kit.
Those are not things that every app will need, so they don’t really have a place in a starter kit IMO. It should be easy to use the starter kit as the base of your app, then add what you need.
For a starter kit Reactstrap would’ve been simpler than styled components. Would you disagree?
It’s great that important features like multi-language and SSR have been implemented, But the code generally appears quite a bit more complex and convoluted than what may be expected from a starter kit, making it more difficult to reason and work with. So I’m wondering whether the complexity is necessary, best-practice, or worth having. There are already over 140 files even though it’s meant to be a skeleton with almost no functionality.
I’d be interested to know others’ experiences of using this starter kit.
I think it’s reasonable to say that it’s not a starter kit aimed at beginners; there are already loads of those available.
The term starter kit might be a misnomer. It’s really the result of frustration when I was trying to find an up-to-date base for a full scale project. It’s a kit for relatively experienced develop to start a project from when you need the technologies that I’ve put into it. I couldnt find anything with all this stuff put together; putting all these technologies together takes time, the kit speeds up that process for you.
I’m curious to know what you find convoluted? If there’re are structural issues then I’ll be happy to address them. I’ve tried to keep the code as clean as possible but they’re is undoubtedly room for improvement.
As for styled components, they should be trivial for you to remove. There are only a few demo pages that you aren’t expected to keep. Create your own home page using React strap and remove the other pages. All that’s left to remove are a couple of related lines in ssr.js.
At first I wondered why there was a need for so many index.js files, which adds extra steps in following code trails.
Then I tried to add a ReactStrap navigation bar component and found that I had to make modifications in many different files to do it. It wasn’t as straightforward as creating a new file with the component code and importing it to use it.
The index.js files are there so that you can import a folder. For example…
import { withSEO } from '/app/ui/hocs';
…will automatically import the file ‘/app/ui/hocs/index.js’. This is standard practise with ES6 imports.
I’ve no idea which files you had to modify for the navigation bar, but really the complexity or otherwise of the UI has little relationship to the starter kit. Adding new React component will be no more complicated than in any other project. The only real difference will be that I’ve demonstrated an AppShell design with a few top level components that get displayed quickly - you don’t need to keep any of it.