Declarative DSL #63
Declarative DSL #63
Conversation
| The following custom elements are recognized: | ||
|
|
||
| * `<app-action>` | ||
| * `<app-actions>` |
There was a problem hiding this comment.
Need to add <app-element>.
Current coverage is 100% (diff: 100%)@@ master #63 diff @@
===================================
Files 11 12 +1
Lines 700 920 +220
Methods 2 3 +1
Messages 0 0
Branches 128 191 +63
===================================
+ Hits 700 920 +220
Misses 0 0
Partials 0 0
|
novemberborn
force-pushed
the
extract-refactorings
branch
from
2005fff
to
5932217
Compare
novemberborn
force-pushed
the
declarative-dsl
branch
2 times, most recently
from
d7d511f
to
dc4a181
Compare
| 'an ID is required'() { | ||
| projector.innerHTML = '<app-widget></app-widget>'; | ||
| return rejects(app.realize(root), Error, 'Cannot resolve widget for a custom element without \'data-uid\' or \'id\' attributes'); | ||
| }, |
There was a problem hiding this comment.
Still need this test.
| @@ -307,9 +305,6 @@ export default function realizeCustomElements( | |||
|
|
|||
| let promise: Promise<WidgetLike> = null; | |||
| if (isWidgetInstance) { | |||
| if (!id) { | |||
| throw new Error('Cannot resolve widget for a custom element without \'data-uid\' or \'id\' attributes'); | |||
| } | |||
There was a problem hiding this comment.
Still need to throw.
Perhaps change message to app-widget requires data-uid or id attribute.
|
Pushed a fixup for my earlier comments, and a big refactor of |
| }; | ||
| } | ||
|
|
||
| export interface Result { |
There was a problem hiding this comment.
At a minimum we should have JSDOC style comments on anything we export...
There was a problem hiding this comment.
Sure, pushing fixups to add comments for new exports.
| } | ||
| else { | ||
| resolve(module); | ||
| require([toAbsMid(mid)], resolve); |
There was a problem hiding this comment.
Should we consider some sort of AMD loader detection and fail gracefully if not support... We might want to also structure this in a way that it is possible that we might environmentally detect other loaders in the future and attempt to code path for resolution there.
There was a problem hiding this comment.
We have dojo-core/load which is designed for loading resources without having to specifically worrying about what loader, but it doesn't specifically load modules (e.g. run them in a context once retrieved)
There was a problem hiding this comment.
Looks like dojo-core/load falls back to the available require method, so that would work for modules right? That would be a follow-up change though.
https://travis-ci.org/dojo/app/builds/164598735 failed due to socket hangups, and |
Support resolving specific, non-default members, as well as (non-default) module contents. Document exports and resolution behavior.
Avoid unnecessarily initializing variables in tests to remove strict null check violations. Silence others. Refactor parsing logic and task typings. This reduces ambiguity and the need for type casts, especially if strict null checks are taken into account. Use a helper method to read attributes. The various task interfaces are declared with optional properties. An object containing undefined property values conforms to such an interface. Use the helper method to return undefined values, rather than null, so non-existing values can be used for optional properties. Ensure task property values are not null. Null values cannot be assigned to optional interface properties. Cast known-string pop() result to string. Splitting a string always results in an array with at least one string element, so popping from that array will never return undefined. Throw when action, store and widget elements have from and factory attributes.
novemberborn
force-pushed
the
declarative-dsl
branch
from
79dfdd4
to
8eedaf9
Compare
Implements most of #33. Supports
app-action,app-actions,app-element,app-storeandapp-widget(for widget registration).Builds on #62.