Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Site refactor #52

Merged
merged 52 commits into from
Jun 24, 2017
Merged

Site refactor #52

merged 52 commits into from
Jun 24, 2017

Conversation

olizilla
Copy link
Contributor

@olizilla olizilla commented Jun 12, 2017

  • Pull html into /content directly (no need for empty .md files in content)
  • Pull head meta and footer to partials
  • Use hugo builtin GA template
  • Add package.json. Subsequent PR will clean up StandardJS warnings.
  • Add .editorconfig (mixed line endings and mixed indent styles exist in project)
  • Simplify .gitignore to only contain file types this project might generate.
  • Pull src JS to top level. Fix html script links.
  • Pull data into json and into hugo data folder. Next step, static build all the things.
  • Browserify the JS, to encourage module client-side code.
  • Decompose common.js into named modules with a single purpose, to ease maintenance.
  • Use factor-bundle to create page specific bundles pull common deps into common.js.
  • Add build:js and watch:js scripts to package.json.
    • build browserifies the JS and outputs the bundles to /static/js.
    • watch does the same but will rebuild the bundles when source file is changed.
  • Partial for topbar nav
  • Implementations page html generated at build time
  • Port impls section on homepage to hugo
    • Refactor implementations.json to preserve item order.
    • Port JS UI code to hugo partial bundle.html
  • Bundles page html generated at build time
    • Refactor bundles.json to preserve item order.
    • Port JS UI code to hugo partial bundle.html.
    • Port "coming soon" section to hugo.
  • Split less files into helpers and page specific files.
  • Replace css imports with less inlining imports, to reduce http requests.
  • Concatenate all site-wide styles into a single common.css bundle.
  • Add build:css, watch:css and clean:css build targets.
  • Pull Logo animation in css off spec, and not a significant issue.
  • Refactor splash animation to use css.
  • Add build step to optimise static resources
  • Add ipfs & dnslink deployment process
  • Contributors generated at build time (as per protocol site)
  • Simplify build process and add a makefile

This list may grow, but this is the story as best we know it right now.

- Pull head and footer to partials
- Use hugo builtin GA template
- Add package.json. Subsequent PR will clean up StandardJS warnings.
- Removes rogue index.css link from common head.html patial.
- Fix line endings in README.md.
- Simplify .gitignore to only contain file types this project might generate.
@olizilla
Copy link
Contributor Author

@diasdavid this is mergable if you have a moment to review. I'm working on fixing up the JS so there are no standard errors next.

@olizilla olizilla requested a review from daviddias June 12, 2017 15:07
- Use factor-bundle to create page specific bundles pull common deps into common.js
README.md Outdated

## Implementations & Bundles

JSON arrays to update implementation & bundle status can be found in `/static/js/data`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation needs to be updated as in "how to update the JSON arrays and what are they containing"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 the README will be fixed up to comply with the README spec, but I'll tackle that last once everything is in place.

README.md Outdated
> hugo
# ..

> ipfs add -r public
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should also explain how to use the DNS simple publish script

@lgierth can we create a test account for tableflip? A simple account with a random domain will do, then all we need is to change the target and API token.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My crappy dnslink script is here: https://github.com/ipfs/infrastructure/blob/master/scripts/dnslink.sh

It needs bash, curl, jq (all in homebrew), and you call it like this DNSIMPLE_TOKEN=<token> ./dnslink.sh <domain> <hash>

<div class="triangle grey"></div>
</article>

</main>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the main should be in body. Anything that is template/design should go into a partials/template folder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will be pulling much more into partials.

When building pages I find it most useful to be able to compose the page out of templates, rather than override things from a layout. A layout either ends up encoding some assumptions, that some pages may not want, or is so thin that it's hardly worth making the dev fit 2 files in there head to guess what the resulting page will be.

@daviddias
Copy link
Member

Good progress here! :)

Since there is more to follow, could you list the items you have in mind with check boxes (example) so that I pointing something you already have in mind? Thank you!

@olizilla
Copy link
Contributor Author

olizilla commented Jun 13, 2017

Taa, much more to follow. If you're happy with this so far, then I'd say let's merge it, and I'll make a checklist for the next one.

- Pull data into json and into hugo data folder. Next step, static build all the things.
- Decompose common.js into named modules with a single purpose, to ease maintenance.
- Fix process to create page specific and common JS bundles.
- Add build:* and watch* scripts to package.json
@olizilla
Copy link
Contributor Author

I've update the PR description to show our progress. The list will grow as the points still to do become more clear as I fix things up, but it's a good start. I'm going to fold all my subsequent branches into this PR.

@olizilla
Copy link
Contributor Author

@diasdavid I'll be working on the build / minify / deploy process and README updates tomorrow. PR is good for your eyeballs now though.

@daviddias
Copy link
Member

daviddias commented Jun 21, 2017

Hey Tableflip! Here is my preliminary review as I test this new hawt 🔥 iteration on the website.

  • package.json needs to be updated
    • remove unnecessary deps
    • remove non used npm scripts
    • make sure that whatever is needed to build the website is part of the Markefile

I've reviewed the website on a train and I've experienced how slow it is to fetch every single image on the contributors graph over a tethered connection

image

Can you make the fetch of those images happen in build step + the crop (less space used), so that the users had to load less content.


Still on the Contributors graph, the horizonal scroll is not working for me now.


This got busted

image


Tiny request: Can we have the implementations.json be one .json per table? It gets exhausting to have to scroll so much.


Let's have anything related with the structure of the website, be inside the layouts folder. By that I mean the js and less into layouts


What's is the difference between the js inside js and the js inside static/js? Looks like there is no transpilation/bundling step, everything can just live in the static/js folder.

@daviddias
Copy link
Member

This is it for now :) Once we get this merged, I'll update the implementations table. There are more implementations already :)

@olizilla
Copy link
Contributor Author

@diasdavid excellent... I'm improving the build process at the moment, so package.json changes will be in there. I've got a nice site build & minify process in npm scripts right now, but I'm pulling it out into a makefile which will be equally nice.

I'll still be using thepackage.json to install the command line tools ensure needed in build are installed locally at known versions specific to the project rather than relying on whatever the user happens to have installed globally.

On the contributors implementation, it'd help me a lot if we could have a call about it. The spec'd change was to have it pull the data in at build time rather than in the browser, but then I couldn't resist simplifying the code once I was in there, but I recognise that I've gone off spec, so it'd be great to sync our expectations on what it should do. Some of it may ideas for the next sprint. In general though, I agree that it's too heavy for mobile clients on roaming data.

I'll fix that busted image now! Pesky OSX and it's case-insensitive file system.

Tiny request: Can we have the implementations.json be one .json per table? It gets exhausting to have to scroll so much.

Yes, but that'll require a change to the rendering logic too so I'd suggest this is more like a good idea for the next sprint.

Let's have anything related with the structure of the website, be inside the layouts folder. By that I mean the js and less into layouts
What's is the difference between the js inside js and the js inside static/js? Looks like there is no transpilation/bundling step, everything can just live in the static/js folder.

Good to chat about this one. Now there is a build step where we browserify the js into per page bundles and extract out all the common code into a common.js file that's loaded on each page, so the idea is that the js folder at the root is the "source js" and the build process will output the production files into the static/js. Same for the less files... I don't have super strong feelings about where the source files live, but it seems wise to keep them separate from the generated files, and somewhere other than the static dir as that triggers hugo magic and implies that they can be served up to the client.

@olizilla
Copy link
Contributor Author

@diasdavid PR updated with fixes and a SUPER SHINY MAKEFILE ...based build and deploy process. The deploy is basically cribbed from other makefiles around the protocol universe, while the build step is a port of the npm run script version, and I think it's pretty rad. Take a look.

Of note, I haven't tested the publish-to-domain target, as I didn't want to actually publish to the domain!

olizilla and others added 5 commits June 22, 2017 15:09
Fix publish-to-domain to use dnslink script
- Decrease minimum time between hexagons
- Trigger contributor loading when the user is within 500px
Makefile Outdated
--domain=$(DNSZONE) --record=$(DNSRECORD) --path=/ipfs/$(shell cat versions/current)
publish-to-domain: auth.token versions/current
DNSIMPLE_TOKEN=$(shell cat auth.token) \
./dnslink.sh $(DOMAIN) $(shell cat versions/current)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lgierth will like this :D

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually let's move the token file to something like $HOME/.protocol/dnsimple.token -- just so it's never underneath the repo directory and there's no chance of ever accidentally committing it.

You can just assume that people put it there out-of-band (dnslink.sh will fail on its own).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lgierth will move this as a separate issue and for a future sprint since last sprint ran out of time.

@olizilla
Copy link
Contributor Author

✨ 🎷 🐩

@daviddias daviddias merged commit 60ab7cc into libp2p:master Jun 24, 2017
@daviddias daviddias mentioned this pull request Jun 24, 2017
2 tasks
@alanshaw alanshaw deleted the move-content branch July 24, 2017 09:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants