V2 [work-in-progress]

[aendra-rininsland]

Okay, lots of stuff going on here.

• views/ has been totally replaced by @financial-times/g-components
• Nunjucks is dead, long live React SSR!
  • In practice, this means that server/index.js does the first pass of rendering the page. Once the client loads the bundle, it re-hydrates with possibly updated state or whatever else.
• I've always hated the Orwell copytext because it way too closely resembles English (and, quite frankly, I find that particular essay to be Orwell at his worst and most pretentious). I've thus replaced it with Lorem Ipsum text in Esperanto and with a boatload of olde English diacritic marks.
• client/ now has two JS files by default — the Webpack entry point (index.js) and the root <App> component (app.js). Would love to simplify this more, not sure if it's possible. Mostly you won't ever have to do anything in index.js.
• The main text blob is now in client/app.js. Currently you can't use Markdown, though that isn't overly difficult to add.
• It dawns on me I've not really surfaced client/components/core/top.css. I may just minify it and put it statically in the <HtmlHead> element of g-components. Doesn't seem to have broken anything, though?
• Worth noting that anything that Origami does on page load might be overwritten by the React client-side rehydration process (which is why <Comments> is a PureComponent and not a stateless component). It's generally better to initialise Origami stuff in componentDidMount(), unless the issue I was running into merely was due to o-comments not loading without a title attribute (in which case some better error logging would be nice...). See source for .
• There are probably some bits around it that are a touch broken (particularly, inline elements need a nbsp of format {' '} in JSX to separate them from the next word when in, say, a paragraph). Please fix these as you notice them and push your fixes to this branch, thanks.
• I've not tested a prod build of any of this stuff yet. It's rather likely the Webpack config will need some tweaking.
• Deps bumped to Babel 7 and Webpack 4. N.b., this is inconsistent with g-components because the latter needs Webpack 3 for Storybook to build properly.

[joannaskao]

How would we change the default layout in individual projects if we wanted to (e.g. add another social button, center the headline, etc...)? I wonder if a commented out example would be helpful.

[joannaskao]

Can we still use the Origami build service? Where would we add that in?

[aendra-rininsland]

@joannaskao —

re: Origami Build Service deps, that's currently hardcoded in g-components. Will make configurable

re: modifying the default layout, it can be done by replicating g-components/Layout and overriding individual components. As g-components matures, more customisation will be possible without having to replicate individual components, though in general it's kind of designed to prevent non-standard design decisions without a bit of work.

[maxharlow]

The more I think about it the more I really like the separate g-components -- I think it's a much better structure. Which made me think -- are there any more parts we could move out into separate, versioned releases? Would be great if the only code you got with Starter Kit was code that you would be very likely to modify -- like client/app.js, config/index.js, etc.

I think the advantages of this approach would be:

• When coming to a (old or new) project it would be easy to understand which bits of code is specific to that project, which bits are defaults from the version of Starter Kit it was built from, and which bits are defaults from Starter Kit that have been modified
• Starter Kit would be less intimidating, especially for people on the team who don't use it so often
• For cases where we return to an old project, it would be trivial to upgrade any of the key parts to a newer version

I'm imagining a fresh future Starter Kit project being just a few files -- one with the main body content, one setting up the build, a config file, a package.json (with just a couple dependencies on g-components, and other g- things), as well as a few dotfiles.

One candidate would be the Webpack build -- could that potentially be pulled out into a g-builder repository? A default Starter Kit project could then have package.json scripts that call it.

What do you think? Good idea?

[aendra-rininsland]

@maxharlow I do quite like that idea, I think we talked briefly last week about creating something that works similar to create-react-app that can be saved as a dependency and then ejected if necessary. I'm inclined to sort that out sooner rather than later to benefit most from all the shared dependencies.

[aendra-rininsland]

Closing and renaming branch to master 🎉