-
Notifications
You must be signed in to change notification settings - Fork 7
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
Update index.html #19
base: master
Are you sure you want to change the base?
Conversation
removed unfinished sentence. Added `Creating your own Extension` Heading did not finish content.
additional: changed two `h4` headings to `h3` headings => To an Extended Voyage and Say Hello to Custom Attribute Accessors. I was going to put an additional example that doesn't use the `type` and also an example with an event to show the versatility of the X-Tag. Let me know what issues their are
// the disabled="" attribute. Because it is declared as a boolean, | ||
// all values passed into its getter/setter will be a Boolean. | ||
this.firstElementChild.disabled = value; | ||
get 'mode::attr'(){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain this part a bit? The template extension itself auto-switches template renders when you change the template via the template setter: this.template = 'myModeSnippet'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So basically what I did here was use it the way your template attribute uses it. I wasn't sure about this myself, did you want to include any content on these types of uses?
In the future I can bring up issues before making a PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minus the promise api bit of course.
==> If you were using other dependencies that used a template attribute using render directly instead of initiating the template setter could be a work around.
I may be mistaken but using the render() method doesn't set the template attribute or am I incorrect, @csuwildcat?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got that mistaken a bit...the render() api will always write the newest template that you summoned into existence...which I thought it wouldn't. Maybe a line in the docs should be added just in case others misunderstand that templates get replaced rather than appended onto the targeted node.
The mode attribute itself was so that you could create different types and than define different modes for those types. I have a bit more for x-tag components concerning types and modes.
I have to push an update to my dashboard build, when I do that I could create a branch with the build that utilizes the x-tags type and mode extension, if you want. It would be helpful, cause I could use some help concerning the event API being used in the extensions being defined. [i.e. they are not firing when added to an extension object]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did more testing with the extensions and got the src plugin running, I guess something maybe out of place somewhere I overlooked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duh I just found it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry for bombing this thread but this is annoying me...I have bit of code working the way its supposed to but it matters what order I put the extensions in. For instance this works =>
XTagElement.extensions("mode","typed",...)
but not
XTagElement.extensions("typed","mode",...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a bug or is their a reason I'm not seeing?
index.html
Outdated
<h4>To an Extended Voyage</h4> | ||
<pre class="language-javascript"><code>// Lets create our X-Tag extension. | ||
|
||
xtag.extensions.lifecycle = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this is absolutely a technically accurate example, I think it could confuse people to see something that looks like the old API/W3C spec - maybe we can get an example that is of a new type of feature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I threw it in there from my own v2 extensions that I'm building. How about making a `xtag.extensions.jenny = { }' example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol sorry xtag.extensions.foo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to commit a different example today.
@csuwildcat, How is this?
removed "*::lifecycle" with "::gobble"
I think its a good idea to commit an extensions example from the jasmine testing what do you think? I think that the examples I used are good but in a hacky sort of way.... |
I agree that the test examples are probably a good idea for this.
…On Wed, Apr 25, 2018, 9:19 PM KIP ***@***.***> wrote:
I think its a good idea to commit an extensions example from the jasmine
testing what do you think? I think that the examples I used are good but in
a hacky sort of way....
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAICyuL1WajnEx1hGwoausd8VGwQ2oiUks5tsUrCgaJpZM4TLaYY>
.
|
This could be a bug, I'm not sure why this would happen. Can you create a
simple Codepen out of this example and link it here?
…On Thu, Apr 26, 2018, 7:00 PM KIP ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#19 (comment)>:
>
-xtag.create('x-bar', class extends XTagElement {
- '::template(true)' (){ return '<input />' }
- set 'disabled::attr(boolean)' (value){
- // The ::attr extended property links node.disabled to gets/sets of
- // the disabled="" attribute. Because it is declared as a boolean,
- // all values passed into its getter/setter will be a Boolean.
- this.firstElementChild.disabled = value;
+ get 'mode::attr'(){
Is this a bug or is their a reason I'm not seeing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAICymlK7aCwUo3jBxhf22mfDi7alqPrks5tsnutgaJpZM4TLaYY>
.
|
Of course.! :) |
https://codepen.io/kipomaha/pen/xjRKwa EDIT: I put comments and the html EDIT: Do you understand the comments @csuwildcat ? EDIT: I thought I changed all the mistaken => (base) => class extends xtagelement {} Good update so far. |
The test case is pretty large, and I can't really track the error well,
given there are many, many JS includes and it is hard to understand the
loading sequence. Can you do something that shows where the x-tag lib is
being loaded, vs the Pen code that throws? You are loading the lib before
the custom code, correct?
…On Thu, Apr 26, 2018 at 7:15 PM, KIP ***@***.***> wrote:
https://codepen.io/kipomaha/pen/xjRKwa
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAICykrYTloOqTTP-QcZbzH_XiT7ngWCks5tsn9VgaJpZM4TLaYY>
.
|
It looks like the Pen is failing to load the base X-Tag JS, which is making
it impossible to debug any subsequent issue that may be in play further
down when you use the lib/extensions code.
On Fri, Apr 27, 2018 at 10:46 AM, Daniel Buchner <[email protected]>
wrote:
… The test case is pretty large, and I can't really track the error well,
given there are many, many JS includes and it is hard to understand the
loading sequence. Can you do something that shows where the x-tag lib is
being loaded, vs the Pen code that throws? You are loading the lib before
the custom code, correct?
On Thu, Apr 26, 2018 at 7:15 PM, KIP ***@***.***> wrote:
> https://codepen.io/kipomaha/pen/xjRKwa
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#19 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAICykrYTloOqTTP-QcZbzH_XiT7ngWCks5tsn9VgaJpZM4TLaYY>
> .
>
|
I am new to codepen. I just started the account, so I dumped a bunch and started reorganizing. When I started to put it onto code pen it became apparent to me what had happened inadvertently. When I created the mixin for the type extension I went and did:
Which was a problem I had earlier [I thought for sure I had fixed them all] but didn't recognize the symptoms, because the |
here is the code pen for the offending file. https://codepen.io/kipomaha/pen/gzLKea?editors=1010 |
I guess what I did was create a custom class mixin... sort of by accident. |
https://codepen.io/kipomaha/full/xjRKwa <= example of my error....nobody should ever do this....... |
@csuwildcat the example of my error is their if you wanted to see what it causes. |
Open the console [may want to drag it so its taller] and you will see the log. |
@KipOmaha this is the output I see on that page: pen.js:28 hi onParse.
pen.js:8 hi onParse.
pen.js:36 testin attr bil.
pen.js:37 hi onConstruct
pen.js:16 testin attr bili.
pen.js:17 hi onConstruct
pen.js:28 hi onParse.
pen.js:8 hi onParse.
pen.js:36 testin attr bil.
pen.js:37 hi onConstruct
pen.js:16 undefined
pen.js:17 hi onConstruct Is the issue line 16 where the value is |
So the code runs the same except that the |
@csuwildcat I made changes to the test case. Below is the log. Okay so the extension gets executed in the order that they appear in the element definitions. So the parse, compile, and construct methods will get executed in the order they appear not in the extension parameters but in the object. I still don't quite get why the order of this matters...I mean the mistake in the
|
removed unfinished sentence.
Added
Creating your own Extension
Heading did not finish content.