[api] Remove helper items, rework navigation index #139
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It turns out that helpers can actually be functions _or_ classes, which
was not something which the original data model took into account.
This PR removes the notion of a unique "helper" type from the data
model in favor of deferring to whatever construct is ultimately
resolved: Either a class or a function.
The navigation index code has also been simplified a bit - it was pretty
hacked together after EmberConf, so it needed some straightening out.
For now, the rule is that every resolvable file gets an entry, and the
the last segment of the file path becomes the entry's name. Helpers and
components are {{curlied}} and everything else is CapitalCased.
We are also no longer making assumptions about what a file is exporting.
This means that if helper function or class is exported from resolved
directory, it will _not show up_ in the navigation at all. We can work
on solving this use case later on, but I think it will be sufficiently
rare that we can punt on it until later. `utils/` folders are
purposefully excluded from this and are placed instead in the module
structure, since that is the most common directory for helper functions.
We also need to consider how this structure may change with module
unification and nesting, but that's a problem for the future.
pzuraq
force-pushed
the
refactor/remove-helper-items
branch
from
88d6db5 to
f80e066
Compare
Contributor
Author
|
Failures are due to an unrelated bug upstream that has been fixed. The fix has not yet propagated to Beta, but everything is green on Canary so going to merge this and publish for now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It turns out that helpers can actually be functions or classes, which
was not something which the original data model took into account.
This PR removes the notion of a unique "helper" type from the data
model in favor of deferring to whatever construct is ultimately
resolved: Either a class or a function.
The navigation index code has also been simplified a bit - it was pretty
hacked together after EmberConf, so it needed some straightening out.
For now, the rule is that every resolvable file gets an entry, and the
the last segment of the file path becomes the entry's name. Helpers and
components are {{curlied}} and everything else is CapitalCased.
We are also no longer making assumptions about what a file is exporting.
This means that if helper function or class is exported from resolved
directory, it will not show up in the navigation at all. We can work
on solving this use case later on, but I think it will be sufficiently
rare that we can punt on it until later.
utils/folders arepurposefully excluded from this and are placed instead in the module
structure, since that is the most common directory for helper functions.
We also need to consider how this structure may change with module
unification and nesting, but that's a problem for the future.
Closes #136