Move to React and static generation

[Dangoo]

Hey @philnash ,

discussing on twitter is funny but kind of imprecise to explain technical implementation details in 140 chars, so move to issues 😄.

How I thought the process might look like this:

• There is a node script that fetches the schedule data for JSconfEU as JSON from the ugly spreadsheet and stores it as file in the git repo
• For the static generation we use React and the fetched JSON (and maybe custom JSON for CSSconfEU) to output the markup as static HTML file with ReactDOMServer.renderToString(App) which also includes the React specific data attributes to allow code reusage during runtime
• In respect to the JS date API the dates are formatted according to node process language (should be english)

So far we got a whole static generated, cacheable version of the schedule together with a bundled JS-file containing templates and application logic. What we can do now is:

• Include React as client side dependency (from a CDN) in the markup
• Include the bundle.js
• re-render the vDOM with react while user already can see the site with user locale etc.
• cache generated HTML for next offline page reload
• Let react perform its magic to diff static generated DOM from server/cache with local computed output

--> See Schedule with localised time format (maybe even LTR/RTL support)
--> Able to update view each minute
--> Same templating for static generation and DOM-Updates

What do you think?

/cc @silkine

[philnash]

I agree, thanks for moving this from Twitter!

Can you make it a bit clearer why we'd need any kind of client side JS, particularly React, other than the simple stuff that is already there? I'm not clear on what the difference will be between the server generated code and the client generated code would be.

Regarding the JSON from the Google Sheet, that's useful except for the fact it disregards the session descriptions, which I think are important when checking a schedule and deciding what to see next. We could add those in by hand, but that's already done in the HTML.

[Dangoo]

According to the design @silkine provided (which indeed was a first concept but has a lot of potential) there is for example a progress indicator for the active talk. It's really useful to see if it's worth to run over to a running talk or if I should better go to the next.
Shure we could write a little snippet that parses all talks from the HTML, queries the <time> element and from the context the date to determine if it's already/still running and how far the progress should be and then manipulate the DOM accordingly.

For other features like toggling the description (good point here with the JSON, probably would need to match that during build…) eventhandling /-binding is required which is pretty nice solved by react as is the diffing algorithm for minimal DOM-Updates.

The downside indeed is the enormous size of React. We could also use NativeJSX which handles the whole event-binding stuff and generates the markup from the templates as DOM-Nodes but requires then a complete replacement of the corresponding markup.

In respect to (possible) features like

• i18n
• LTR/RTL
• Custom shedule (alias integrated selection of talks and custom Talk view)
• …

it's far more extensible and as developer pretty good to read and maintain, since this project as quite an impact and could return the years to come 😉

Maybe I'm thinking too big, but it's big fun.
I18n for dates is already implemented^^

[philnash]

The design comes with whole bunches of problems I'm afraid. The fact that I can't see what two talks are on at the same time without what looks like swiping between the screens is the major killer for me. There is also no selection for what day you are looking at.

The time elapsed in the talk feature feels like a massive over-engineering of a user's ability to look at the current time and see how much has elapsed since the start of the talk.

There are no DOM updates when toggling the description aside from setting a class. This does not require the size or impact of React to handle the event binding, that's already been handled by native DOM event handling.

(Admittedly, the class setting functions could do with an update, but since they work I don't feel inclined to change them.)

I'm not sure what you mean by i18n? The conference is held in English, the website and all talk titles are in English. Internationalising the dates (and changing LTR/RTL) seems out of place in general.

I would like to build a custom schedule function in the future, including notifications. It was on my to do list for this year, but I ran out of time.

Right now, I'm optimising this site first and foremost for offline-ability, speed (download size) and readability. I'm taking some inspiration from @silkine's design, but given the little time until the conferences not making a major overhaul.

I'd love to improve this for further years, and make it more accessible to other conferences to use then the work for that would ideally start after this conference.

You are, of course, welcome to fork this repo and host your own React powered version of the site.

[Dangoo]

Of course i18n is not necessary but it comes with no price. And while I'm used to one time format it's for example just easier for me to read 24h instead of "splitting my day in after and before midnight".

I'm sure it's not a problem to add things like Conf/Day selection above the schedule list. Just out of curiosity what is the main issue with swiping versus tabs where I can't see everything on one glance either?

BTW: Did you use find & replace, handcrafting or is the markup generated? Where can I find the templates?

In the end it is your repo and your choice, just want to help :)

[philnash]

I18n sounds like it comes at the price of React on the front end from what you were saying earlier.

The side swiping in the original design was between tracks for JSConf. I wanted to see them on the same page. To use that for the days of the conference instead wouldn't be so bad. It is somewhat overcomplicating tabs though, I'm not sure what exactly it adds, apart from being slightly fancier.

This markup is handwritten. Mostly just the text updated this time around. I'll have templates next time, I swear!

[Dangoo]

Not necessarily, it makes it just a bit simpler from a devs perspective^^
It would work pretty good too for "regular" markup. A bit of JS searching for example for all <time> elements with attribute datetime set and could fill/replace the content of the element according to the parsed timestamp. This could also enable highlighting of current tracks.

Ah now I', getting the point with the tracks and parallel talks :)
So needs some adjusting maybe…