Comments (7)
Closing as I think this was taken care of?
from calcite-design-system.
It would be more correct to say that there are currently two sources of truth for state: changes to props or changes to the underlying DOM are both respected and propagated to one another. This is in order to support both the wrapped and non-wrapped syntaxes:
<calcite-switch></calcite-switch>
<calcite-switch>
<input type='checkbox' />
</calcite-switch>
One solution would be to disambiguate internally between these two fairly distinct use cases: if no checkbox is provided, treat props as the source of truth. If a checkbox is provided, treat the DOM as the source of truth.
This would allow the component to maintain a single-direction data flow, preventing a whole class of nasty bugs.
from calcite-design-system.
@patrickarlt this passing in your input approach makes the story for these components kind of complicated and adds a lot to the implementation. We could move a lot faster if we removed this requirement.
Wondering if we should go out of our way for this at v1. Maybe bindings for other frameworks are a feature add in the future?
from calcite-design-system.
For posterity I'll post this here in addition to Teams:
https://github.com/ionic-team/ionic/tree/master/core/src/components/checkbox#angular
Ionic, which uses Stencil internally, is able to support Angular's special attribute syntax, like<ionic-component [(ngModel)]='something' />
. I'm trying to understand how they're able to do this, and how @ionic/angular
contributes to that. They certainly don't wrap every single component.
from calcite-design-system.
I think Angular and Vue can pretty much use Ionic's web components directly (with some exceptions: Vue's ionic-tabs for some reason, detailed here).
React is different. Every component has to be wrapped. Mostly this is done semi-automatically using a helper function called createComponent.
from calcite-design-system.
@vcolavin this depends on what you mean by "use directly" and the level of support we want to provide for each framework. Ionic ships a set of Angular bindings so if by "use directly" you mean:
<calcite-switch (switched)="onSwitched(e)" [switched]="isEnabled"></calcite-switch>
You can actually do that without the Angular bindings because it just uses the DOM events and attributes directly.
But if by "use directly" you mean how you are SUPPOSED to do Angular forms like:
<calcite-switch [(ngModel)]="isEnabled"></calcite-switch>
Then you need the bindings. For example here are the <ion-toggle>
bindings.
The reason we do things like:
<calcite-switch>
<input type='checkbox' />
</calcite-switch>
Is discussed in #24 (comment) but to summarize:
- We avoid having to write and maintain binding for every framework.
- Standard browser behaviors like wrapping
<calcite-switch>
in a<label>
work because the standard browser behavior will be to update the nested<input>
which will then update the switch.
@paulcpederson @vcolavin this honestly just seems like a bug we need to fix and write solid regression tests for which I can do after UC.
@paulcpederson we could remove the requirement for this work as per #67 but I think that would be a mistake since it would encourage writing lots of custom additional behavior in the bindings and it would be lots of work the first team that would be implementing these i.e. I have to write Angular binding just to use these in VTSE and then every other team writes their own bindings. I suppose we could already start looking into Stencil DS which is supposed to be able to automatically write the binding for you if we want to have this discussion now. But I honestly feel like this is bug to be solved and not cause us to rethink the whole approach.
from calcite-design-system.
Thanks for the well-thought-out comment @patrickarlt! I agree that this is just a bug that just needs to be fixed. And maybe this isn't the time or place to relitigate the basic approach to writing calcite-components. I did come onto this project when it was already in progress. It sounds like there are serious downsides to the wrapper route.
But because this is intended to be a library which is used and maintained across Esri products for a long while, we will want to prioritize maintainability and code quality. Circular updates stand out to me as a maintainability and readability red flag. I want to find some way or pattern that makes them harder to write, in the same way that React and other modern frameworks protect against them.
from calcite-design-system.
Related Issues (20)
- Tile directly reassigns CSS variables within the component
- Cannot set `min`/`max` constraints on input with `datetime-local` type
- Input-date-picker displays incorrect value if out-of-range
- List Item - make it more obvious when drag-disabled HOT 5
- [Notice] improve text end padding HOT 1
- [List Item] Selection padding has too much space when the List's width is reduced HOT 4
- Cannot reliably restore an input-time-zone's `value`
- `input-time-zone` with empty string not defaulting to local time zone
- Dragging a list item with a specific input contained within it casues a console error
- [Tooling] Communicate component deprecations and upcoming removal via console
- [Pick List] Remove deprecated component from code base
- [Value List] Remove deprecated component from code base
- Epic: Interactive states across the design system for hover, action, and press
- Truncating/shrinking `datetime-local` input can obscure picker button
- calcite-date-picker changes height depending on months
- `type-fest` build error after upgrading to Calcite 2.8.0 HOT 2
- Research a way to share markup between demo.html and "allVariants" story HTML HOT 1
- [List and List Item] Cancel drag reorder on ESC
- `input-time-zone` emits multiple open/close events when toggling `open`
- [calcite-input]: file type emits "Failed to set the 'value' property" error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.