What about support for data-* attributes?
See original GitHub issueI noticed I can add data-* attributes to the virtual dom and they work as expected both with React and Inferno. I’m curious about why this doesn’t work with Preact. Is that on purpose. What would be the reason for that? I just get an empty dataset
with Preact.
Issue Analytics
- State:
- Created 6 years ago
- Comments:34 (8 by maintainers)
Top Results From Across the Web
dataset & data-* attributes | Can I use... Support tables for ...
Partial support refers to being able to use data-* attributes and access them using getAttribute . "Supported" refers to accessing the values using...
Read more >Using data attributes - Learn web development | MDN
HTML is designed with extensibility in mind for data that should be associated with a particular element but need not have any defined ......
Read more >A Complete Guide to Data Attributes | CSS-Tricks
Everything you ever wanted to know about data attributes in HTML, CSS, ... This browser support data is from Caniuse, which has more...
Read more >Customer Data Attributes - Re:amaze
Customer data attributes are data points about your customer. The customer data attributes will be displayed under the first message of every conversation ......
Read more >Reference data attributes - Informatica Documentation
You can create custom attributes that support reference data from other assets. These reference data attributes allow you to use code values in...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
the fast vdom libs have very low overhead [1]. most of the slowdown will be from the fact that you have a huge DOM for the browser to render rather than a huge backing vtree. “over one thousand” is peanuts 😃
[1] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html
A lot of the complexity and size in datepickers comes from those edge cases as @leeoniya pointed out. If you can skip them, skip them. The Canadian VS US dates you can probably do as a display mechanism if you’re using VDOM (data doesn’t have to be displayed in the same format as it is held/edited). I agree the numbers you’re looking at actually aren’t that bad, and Code Splitting seems like an easy bit of low-hanging fruit.