WenInCode

• NB Numeric 574 Vulc Shoes (White, Size 10)
• Gymshark Element Baselayer Leggings (Black, Size M)
• Gymshark Geo Seamless Long Sleeve T-Shirt (Black, Size Large)
• Gymshark Arrival 5" Shorts (Black, Stone Grey, Olive, Size M)
• Running socks (Size L)
• Adidas Heat.Rdy Running Socks (Size L)
• [Lululemon Power Stride Crew Sock (Size

WenInCode

Callaway preowned hybrid - 4 or 3 tensei blue 75

Adidas Retro Cross spikeless golf shoe - white - 10

Nike dri-fit hat black

A golf range finder (idk much about them, defer to papa)

WenInCode

I've made an effort to document what API endpoints we are using where and for what. The example responses here are just mock data, so I would also recommend referencing the documentation which I will link to and the endpoints themselves. Originally I was going to go tab by tab; however, a few of the endpoints are used across tabs. I indicated that in the usuage on the endpoints. If you have any questions feel free to comment here or reach out to me.

All /v1/**internal**/... endpoints don't have public documentation, as far as I can tell.

It also seems like service instances make use of these endpoints instead of their being service instance specific endpoints. I'll be happy to dig into that further should it be helpful.

Services list page

GET services list item

WenInCode

List Item

Originally the structure of the list items was made up (in my mind) of a ListItemContainer, ListItemTemplate and the ListItem encapsulation of both of those. However, after looking at how HDS implements their components we've had a bit of a change in direction that we wanted to share and discuss.

The list item is a generic component, which won't always be the case for component inside the toolkit. The <Cut::ListItem /> will be the container li itself and the container for all the content. It will handle options for how interacting with the entire list item will behave (switch routes, call a function, do nothing) and will represent the states of the li accordingly. It also houses a slot for generic content, allowing anyone to fill that area with whatever they would like. On top of that it will have a slot for actions that will be separate from the main clickable area of the list item to avoid buttons inside of buttons, or buttons inside of anchors, etc.

WenInCode

import Ember from 'ember';

export default Ember.Controller.extend({
  appName: 'Ember Twiddle',
  store: Ember.inject.service(),
 	
  init() {
    this._super(...arguments);
    Ember.run.later(() => {
      this.get('store').pushRecord('foo', {

WenInCode

import Ember from 'ember';

export default Ember.Controller.extend({
  appName: 'Ember Twiddle',
	data: { cluster: { type: 'pg' }},
  
  computedTopLevel: Ember.computed('data', function() {
		return this.get('data.cluster.type') === 'pg' ? 'POSTGRES' : 'MYSQL';
  }),

WenInCode

import Ember from 'ember';

export default Ember.Controller.extend({
  appName: 'Ember Twiddle',
  actions: {
    firstAction() { alert('first action'); },
    secondAction() { alert('second action'); }
  }
});

WenInCode

import Ember from 'ember';
import MyMixin from '../mymixin';

export default Ember.Controller.extend(MyMixin, {
  appName: 'Ember Twiddle',
  init() {
    this.sayThing()
	}
});

WenInCode

<button {{action toggleAction}}>Toggle</button>

WenInCode

Keybase proof

I hereby claim:

• I am wenincode on github.
• I am wenincode (https://keybase.io/wenincode) on keybase.
• I have a public key ASC_dGso-iXAyvTWnj3QfD1gRzN37cGsbhP3VZkui2oAYgo

To claim this, I am signing this object: