Closed ngokevin closed 7 years ago
Yeah boilerplates are complete mini applications that illustrate a speficic application of a-frame
Tests show a specific feature in isolation. They can be more abstract than showcases. The purpose of these is simple working examples we can point people too and also for our manual integration tests
This issue is a bit too broad to tackle. Will try over time to have these out, maybe via Glitches and some in the A-Frame School.
Description:
I was working within a separate aframe-boilerplates repository. After about a week of thinking, it'd be best to move them into the A-Frame repository to consolidate.
My idea on how we'd work on examples:
Showcase
The Showcase consists of examples that are easy to learn from, demonstrate features, and demonstrate use cases. Essentially the type of examples in
aframe-boilerplates
will live here. Showcase examples that are not easy to learn from (anime UI) or demonstrate use cases (anime UI, composite, curved mockups) will be moved out.Examples that I imagine would soon live in Showcase:
The showcase will have a package.json to be published to NPM. The A-Frame site can automatically install them to showcase on the homepage with source code + links.
The condition would be that examples allow for some "second-party components" (i.e., third-party components we approve). They won't have to be committed into the repo or installed, I have them linking to npmcdn (e.g.,
<script src="https://npmcdn.com/aframe-firebase-component@3.0.0">
).Each example would have a guide/case study on how it was built in the
README.md
. I can have the aframe-site consume these and add it to the docs automatically.Boilerplates
Since the new showcase act as boilerplates, we can get rid of the
boilerplates/
folder.Organization
I would also consolidate the
primitives/
,performance
, andanimation/
intotest/
. That way the showcase isn't hidden away in a folder. I'd also move allassets/
to theassets
repo. The new folder structure would look like: