WebComponents training

[justinbmeyer]

Intro

• giving an analogy with jQuery and how web components spawned from it (this isn't backed up by content on the page)
• talking about appendChild without an example of it.

[justinbmeyer]

Why web components

• giving a lot of information about the DOM that folks might not know
• custom elements, templates, etc needs examples ... template literals
• question about web component browser support
• shadow dom - show a youtube video
• question about render performance of encapsulated styles
• custom events example - tabs

Web components serve many purposes:

• share with other teams ... stripe example ...
• Saas - salesforce building with web components
• Used github's details-menu as a semi-example of progressive enhancement

Thoughts:

• "I've talked enough"

[justinbmeyer]

Our first component

• I like the "hello world" introduction, this isn't in the guide
• Must have a dash in the name - told, not shown in the guide. Also, the reason why there must be a dash was asked for, but we didn't have that in the guide.
  • I think we need so show how the component is going to be used. (I think we also didn't talk about the problem / what you need to know / solution structure)
• Showing how to use (add <my-greeting> to the page) before defining it.
• Hooks into "html" ... it's more like the dom. I would connect w/ the dom apis like .innerHTML because the guide just showed that.
• Must extend HTMLElement
• Through attributes like <my-greeting foo="bar"/>
• static get ... might want to give people a small class example
• observe attribute shows listening ... but not doing anything ... maybe console.log("it changed")
• getter / setter ... show changing a property, and console.log() it changed
• we should give people a codepen training
• we should give people the set timeout stuff P0

Thoughts:

• Justin - the attr/prop bindings probably make this beyond a "hello world"

[justinbmeyer]

Writing a template

(Justin was ordering for much of this)

• Examples should be codepen-able

• Result is a gray square ... might want something a bit nicer.

• Would you include the <template>'s in the page?

[moschel]

• Building wifi wasn't working for one guy sitting next to me. Should always have a hotspot that can connect to a data plan handy as a backup for internet.

[moschel]

bus-tracker component

• a little hard to read the screen
• good job encouraging people to ask questions and rewarding those questions
• a little unclear (maybe just because I walked in late) if this exercise is expected to pick up from where the last one left off
• maybe add a "list of buses will go here" in the white space, to make it clear where we're going
• might want to create more clear timing expectations for how long people will be given for writing code, and what you expect them to be doing during that time. ideally like 5 minutes with a running clock and a list of objectives they need to drive towards.
• maybe having everyone pair with someone else would help increase engagement?
• in the listing routes section, the instructions don't explain how to construct the API endpoint string

[moschel]

• the element that shows bus status (upper right corner overlay in the map) probably doesn't need to be a button. not sure why it's a button if it's not intended to be clickable