* web: update TagElement with tagName: String
Enable changing the tagName value. This will delete the initial html element and create a new one with a new tagName.
Cache ElementBuilder instances.
* add comments
* update PR according to discussion
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
* web: apply `classes` before all other attributes and properties
This mitigates "Flash of unstyled content"
* apply style {} before attr(...). Add more tests
* use val instead of var for classes
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Using one version of Gradle improves build
performance and dev experience by
reusing Gradle daemons, using less storage
& copying for Gradle cache, etc
* move to kotlin 1.6.10-RC and corresponding compose commit
* Update path to the karma plugin we are patching
* Add ExperimentalComposeWebStyleApi
what worries me that this actually shows that there are some cases where without any changes apart version compiler people will have to worry about such annotations
* update kotlin version in templates to adopt 1.6.10-RC
* web: move ComposableWithNullableTypeParameter.kt to passing test cases
* update kotlin version in other places
* update imageviewer example: add OptIn for experimental API
* move compose
* move to kotlin 1.6.10 and corresponding compose
* move to kotlin 1.6.10 and corresponding compose
* move to 1.0.1-rc2
* move to 1.0.1-rc2 (todoapp)
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Co-authored-by: Shagen Ogandzhanian <shagen.ogandzhanian@jetbrains.com>
Remove:
```
__LATEST_COMPOSE_RELEASE_VERSION__
__KOTLIN_COMPOSE_VERSION__
System.getenv("COMPOSE_TEMPLATE_COMPOSE_VERSION")
```
They pollute templates/examples.
Now, all paths where we need to change the version are hardcoded in the script.
Usage:
```
./replace.sh 1.0.0-rc6
```
This script is planned to run on CI
In the future I will add support for changing Kotlin version
* web: workaround flaky CI test runner
* Move config path to test-utils/conf/karma.config.common.d
* Reusing same karma config everywhere aprt benchmarks
it looks like we can have only one karma config directory
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Co-authored-by: Shagen Ogandzhanian <shagen.ogandzhanian@jetbrains.com>
* web (breaking change): Make CSSSelector constructors internal and move constant selectors instances to `SelectorsScope`
* web (breaking change): Make CSSSelectors classes internal
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
* web (breaking change): move top level functions for css selectors to new SelectorsScope
These functions don't need to be on top level because their purpose is to be used within StyleSheet
* web: update CSSSelector plus operator
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Options were never actually applied and there was no way to use anything beside Options.DEFAULT
It's still possible to set options using k/js `addEventListener` on the element's reference
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Shagen Ogandzhanian
Oleksandr Karpovich
Oleksandr Karpovich
Shreck Ye
Philip Wedemann
Martynas Petuška
Alexey Tsvetkov
Alexey Tsvetkov
Igor Demin
Abasov Akif