Check out the FAST Component explorer to see it in action: https://explore.fast.design/ Looks very flexible but the presentation and default design is horrible.
Good. That will encourage people to change it.
31–40 of 216 posts
Check out the FAST Component explorer to see it in action: https://explore.fast.design/ Looks very flexible but the presentation and default design is horrible.
Good. That will encourage people to change it.
Check out the FAST Component explorer to see it in action: https://explore.fast.design/ Looks very flexible but the presentation and default design is horrible.
Check out the FAST Component explorer to see it in action: https://explore.fast.design/ Looks very flexible but the presentation and default design is horrible.
I would imagine the design convention is to show a + when you have more content hidden, and a - to indicate you can hide (minimize) it. Is that the popular consensus, or is that an odd way of looking at it?
I love seeing a wider adoption of webcomponents, but I have some complaints about this library, mainly because they're really pushing the whole, "lightweight and low memory" lines. Take a look at the accordian component (the very first one in their system) and check it out in the dom inspector - it has a shadowroot that has precisely one child: a element. In this situation a shadowroot does nothing to help. All it me…
Ok, so it looks like the main point of this is fast-components, which is a just a bunch of components styled as MS-style, but I'm more interested in the fast-foundation package. According to the instructions: > The exports of this package can generally be thought of as un-styled base components that implement semantic and accessible markup and behavior. > it exports parts and pieces intended to be composed into Web C…
I love seeing a wider adoption of webcomponents, but I have some complaints about this library, mainly because they're really pushing the whole, "lightweight and low memory" lines. Take a look at the accordian component (the very first one in their system) and check it out in the dom inspector - it has a shadowroot that has precisely one child: a element. In this situation a shadowroot does nothing to help. All it me…
To my understanding of these components, because they are meant to be styled by the user or a downstream design system the component authors don't know ahead of time where style encapsulation needs to happen, so this approach makes sense for that.
Allow me to ask the obvious question: How does Fast compare against React, Angular, VueJS, etc.?
It doesn't. It's more comparable to something like Google Polymer[0] They can be used in conjunction with eachother[1][2], so I'd imagine the same/similar would be possible with Fast. [0] https://en.wikipedia.org/wiki/Polymer_(library) [1] https://www.digitalocean.com/community/tutorials/vuejs-vue-i... [2] https://github.com/jscissr/react-polymer#readme
It looks like LitElement but more TypeScript first. The decorators do make it a bit more approachable for me.
The big difference from Fast is that LitElement's render() method is an instance method, so it can access any state with `this.` and any properties and methods it uses can be overridden. But it's all just as declarative:
import { LitElement, customElement, property, html } from 'lit-element';
@customElement('hello-world')
export class HelloWorldElement extends LitElement {
@property()
name: string = 'World';
render() {
return html`
Hello ${this.name}
`;
}
}
We have decorators for reactive properties, registering elements, shadow root queries, and adding event listener options to methods: https://lit-element.polymer-project.org/guide/decorators