Add styleguide in repo addon using freestyle

[ed-huang]

What's in this PR?

• Add-on Ember Freestyle
• Added donation components

[ed-huang]

@joshsmith

• definitely feel like this will make things easier to get the ball rolling. Using freestyle gives us a nice framework for components to be put in.
• Somethings are a little opinionated, but sure we can work around.
• Not sure how I feel about everything being inside one template file. Might be hard to collaborate?

[joshsmith]

Everything in one template definitely would make things a challenge.

Is there also a way to prevent freestyle from being deployed (including the assets) alongside our application? i.e. I wouldn't want everything that's intended for use for local development to be made available in our public site, nor burden users with downloading a bunch of CSS/JS they don't need.

[ed-huang]

Yeah we can do that. It'll be similar to the previous styleguide.

[ed-huang]

@joshsmith

• Even though it's all inside one template, each section can be inside it's own separate component. Which makes things more maintainable. sg/folderName--component-name
• As for assets, the freestyle addon can be blacklisted, but I'm not sure about removing the components code

[ed-huang]

@snewcomer sorry for long delay and no response. Hopefully you're still interested in helping out. :) I closed the previous styleguide branch in favor for this one using ember-freestyle instead of starting from scratch.

@joshsmith i was able to move the styleguides into it's own in-app repo so it can be blacklisted. I think we're ready to go?

[snewcomer]

@ilovethebends Awesome work! I love it so far. A few things...do the tests need to be committed/should there be tests? Also, is the idea to document every component in the application or just ones that we think are reused more than once (like a button style, link hover, etc)?

[ed-huang]

@snewcomer Unless anyone can think of a reason, I don't see a reason for tests.

There is no process of which components should or shouldn't be documented. Right now i'm just going through the tests folder to see what I can come up with.

[joshsmith]

I'm seeing some "usage" notes in here that don't seem to represent actual usage but things about the test setup.

Is there a better way we can be handling this?

[ed-huang]

@joshsmith I could just copy the actual component.js in the usage? There was some async stuff i tried to simulate. ie loading repo, syncing repo etc..

[joshsmith]

No I mean, isn't the usage supposed to be the handlebars? Or am I confused?

[ed-huang]

Okay, so now i'm confused too.

I was assuming that usage is both handlebars and data that gets passed in, and how actions might be used? That's why each of the actual components is wrapped inside of a sandbox?

Sorry if i'm misunderstanding you. Usage "notes" can come from using either:

1. the .hbs {{#freestyle-note "globally-unique-slug--notes"}} (not used in this example)
2. or the .js /* BEGIN-FREESTYLE-USAGE globally-unique-slug--notes

In the example above "Connected Installation" code snippets both is coming from the commented section in the .js file. styleguide/components/github/connected-installation.js

The bottom half is where the component is rendered and the handlebars snippet is from the .hbs file.

This is from inside the "usage" helper {{#freestyle-usage 'globally-unique-slug

styleguide/templates/components/github/connected-installation.hbs

{{#freestyle-usage 'github--connected-installation' title='Connected Installation'}}
  {{github/connected-installation
    disconnect=(action disconnect)
    connectRepo=(action connectRepo)
    disconnectRepo=(action disconnectRepo)
    organizationGithubAppInstallation=organizationGithubAppInstallation
    project=project
  }}
{{/freestyle-usage}}

I could just remove all the notes and just render the component and code snippet if you think that's more clear?

[joshsmith]

@begedin could we have your thoughts here on this?

[joshsmith]

To me the bottom code is useful (the hbs) to render, whereas the top part (sandboxed data) being rendered feels not as useful and perhaps even confusing to someone reading the docs expecting to see how it's used.

[joshsmith]

For me, pending that change, getting tests passing again, and giving me some time to take it for a spin, I would then consider this mergeable and we can create a tracking issue for the components we'd like to prioritize next.

[joshsmith]

I'd also love to see a follow-up issue to expand our documentation (perhaps with a link to the wiki for easier doc-writing) to include some thoughts on how we intend to use this and how it can make the development lifecycle easier.

[joshsmith]

Looks like test failures are just eslint, btw.