Skip to content
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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Update index.html #19

wants to merge 5 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Apr 8, 2018

removed unfinished sentence.
Added Creating your own Extension Heading did not finish content.

KIP added 2 commits April 8, 2018 01:32
removed unfinished sentence.
Added `Creating your own Extension` Heading did not finish content.
added a line for `creating an extension`
moved `creating an extension` up a section
@ghost
Copy link
Author

ghost commented Apr 8, 2018

closing pull request #16
this PR contains all the changes from the #16

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'(){
Copy link
Member

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'

Copy link
Author

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.

Copy link
Author

@ghost ghost Apr 13, 2018

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?

Copy link
Author

@ghost ghost Apr 25, 2018

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]

Copy link
Author

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.

Copy link
Author

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.

Copy link
Author

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",...)

Copy link
Author

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 = {
Copy link
Member

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?

Copy link
Author

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?

Copy link
Author

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

Copy link
Author

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.

KIP added 2 commits April 18, 2018 13:37
removed "*::lifecycle" with "::gobble"
@ghost
Copy link
Author

ghost commented Apr 26, 2018

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....

@csuwildcat
Copy link
Member

csuwildcat commented Apr 26, 2018 via email

@csuwildcat
Copy link
Member

csuwildcat commented Apr 27, 2018 via email

@ghost
Copy link
Author

ghost commented Apr 27, 2018

Of course.! :)

@ghost
Copy link
Author

ghost commented Apr 27, 2018

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 {}
to =>
(base) => class extends base{} ....sorry.... :(

Good update so far.

@ghost ghost mentioned this pull request Apr 27, 2018
@csuwildcat
Copy link
Member

csuwildcat commented Apr 27, 2018 via email

@csuwildcat
Copy link
Member

csuwildcat commented Apr 27, 2018 via email

@ghost
Copy link
Author

ghost commented Apr 27, 2018

I am new to codepen. I just started the account, so I dumped a bunch and started reorganizing.
The Problem was resolved, though.
Sorry for the false alarm...long story short I thought I had fixed all the part in the code but missed an occurrence of it in the mode.js file.
MORE DETAILS BELOW. It is a strange occurrence and is a stable way to build a mixin if you had a diff library that you wanted to incorporate.

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:

mixin: (base) => class extends XTagElement {}
instead of
mixin: (base) => class extends base {}

Which was a problem I had earlier [I thought for sure I had fixed them all] but didn't recognize the symptoms, because the oncompile , onparse, and onconstruct were working.

@ghost
Copy link
Author

ghost commented Apr 27, 2018

here is the code pen for the offending file. https://codepen.io/kipomaha/pen/gzLKea?editors=1010

@ghost
Copy link
Author

ghost commented Apr 27, 2018

I guess what I did was create a custom class mixin... sort of by accident.

@ghost
Copy link
Author

ghost commented Apr 27, 2018

https://codepen.io/kipomaha/full/xjRKwa <= example of my error....nobody should ever do this.......

@ghost
Copy link
Author

ghost commented Apr 27, 2018

@csuwildcat the example of my error is their if you wanted to see what it causes.

@ghost
Copy link
Author

ghost commented Apr 27, 2018

Open the console [may want to drag it so its taller] and you will see the log. x-bili doesn't see the bili attribute

@csuwildcat
Copy link
Member

@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 undefined?

@ghost
Copy link
Author

ghost commented May 5, 2018

So the code runs the same except that the XTagElement.extensions("bil","bili",...) is switched up so that the custom extensions are presented as parameters in a different order in each custom element, @csu wildcat.
The order causes it to be undefined in one custom element and not the other. It's kind of confusing...sorry :(
-- EDIT: @csuwildcat so yeah it was cause it was undefined and I couldn't figure it out. I had the extension in a separate file and forgot to fix an error. It confused me cause when I switched the order of the extension parameters it would work. Sorry for the confusion.

@ghost
Copy link
Author

ghost commented May 5, 2018

@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 mixin I made should have thrown an error I would have thought intuitively but it runs in some cases making it hard to identify when boxing with multiple JavaScript element definition files.

 Parsing `bib` extension.   ------   xjRKwa (85,5)

 Parsing `bar` extension.   ------   xjRKwa (66,5)

 Parsing `bal` extension.   ------   xjRKwa (104,5)

 Compiling `bib` extension.   ------   xjRKwa (88,5)

 Compiling `bar` extension   ------   xjRKwa (69,5)

 Compiling `bal` extension.   ------   xjRKwa (107,5)

 Constructing `bib` extension for:    ------   xjRKwa (91,5)

<x-foo bal="x-foo" bib="x-foo" bili="x-foo"></x-foo>

 Testing attr getter `bil`.   ------   xjRKwa (93,5)

 Result:true   ------   xjRKwa (94,16)

 Constructing `bar` extension for:    ------   xjRKwa (72,5)


<x-foo bal="x-foo" bib="x-foo" bili="x-foo"></x-foo>

 Testing attr getter bili.   ------   xjRKwa (74,5)

 Result:true   ------   xjRKwa (75,17)

 Constructing `bal` extension for:    ------   xjRKwa (110,5)


<x-foo bal="x-foo" bib="x-foo" bili="x-foo"></x-foo>

 Testing attr bal.   ------   xjRKwa (112,5)

 Result:true   ------   xjRKwa (113,16)

 Parsing `bib` extension.   ------   xjRKwa (85,5)

 Parsing `bar` extension...   ------   xjRKwa (66,5)

 Parsing `bal` extension.   ------   xjRKwa (104,5)

Compiling `bib` extension.  ------   xjRKwa (88,5)

 Compiling `bar` extension  ------   xjRKwa (69,5)

 Compiling `bal` extension.  ------   xjRKwa (107,5)

 Constructing `bib` extension for:   ------   xjRKwa (91,5)

<x-tup bal="x-tup" bib="x-tup" bili="x-tup"></x-tup>

 Testing attr getter `bil`.  ------   xjRKwa (93,5)

 Result:true  ------   xjRKwa (94,16)

 Constructing `bar` extension for:  ------    xjRKwa (72,5)

<x-tup bal="x-tup" bib="x-tup" bili="x-tup"></x-tup>

 undefined  ------   xjRKwa (74,5)

 Result:false  ------   xjRKwa (75,49)

 Constructing `bal` extension for:   ------   xjRKwa (110,5)
 
<x-tup bal="x-tup" bib="x-tup" bili="x-tup"></x-tup>

 Testing attr bal.  ------   xjRKwa (112,5)

 Result:true   ------   xjRKwa (113,16)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant