Releases: JetBrains/compose-multiplatform
v0.5.0-build226
Desktop
Breaking changes in Composable Window API
Window(onCloseRequest=)
is required parameter nowWindowState.isMaximized
,WindowState.isFullscreen
are merged toWindowState.placement { Floating, Maximized, Fullscreen }
WindowPosition
is sealed class{ PlatformDefault, Aligned, Absolute }
,initialAlignment
removed from Window/Dialog
Compose for Web 0.5.0-build225
Changes in API
More HTML tags available from the box:
- Content sectioning:
Address, Article, Aside, Header
- Multimedia:
Area, Audio, HTMLMap (<map>), Track, Video
- Form:
Datalist, Fieldset, Legend, Meter, Output, Progress
- Embedded:
Embed, Iframe, Object, Param, Picture, Source
The attr
method no longer accepts nullable values (breaking)
Null values were used only to tell API to skip attribute assignment at all. The other, closely related, change is that
Boolean attributes no longer accept Boolean flag as parameter (breaking)
before | 0.5.0-build225 |
---|---|
attrs { disabled(value = isDisabled) } |
attrs { if (isDisabled) disabled() } |
The change affects the following attributes: autoFocus, disabled, formNoValidate, autoComplete, noValidate, autoComplete, checked, multiple, readOnly, selected, required
.
The thing is that whenever we wrote code like this
Button({ disabled(false) })
it takes some mental effort to realize that this attribute was just not added at all. This is rather tricky (and non-idiomatic) way not to add an attribute. So, we've decided to just, well, not call anything in such cases.
Tag interface has been removed (breaking)
If you haven't extended any DOM entities you can just skip this section, these changes won't affect you.
Initially, we introduced the Tag
interface to separate attribute scopes (so that one, for instance, won't call href
on div
etc.).
Having hard times with CSSOM, we just weren't sure that the standard DOM API provided in browsers would be sufficient for our purposes.
However, now we are lucky enough to acknowledge that we can rely completely on standard DOM types hierarchy.
If you have some tags declared in your code, just choose HTMLElement
subtype that you will use as context:
before | 0.5.0-build225 |
---|---|
fun AttrsBuilder<Tag.A>.href(value: String?) = attr("href", value) |
fun AttrsBuilder<HTMLAnchorElement>.href(value: String) = attr("href", value) |
This week in Compose for Web
We've decided to add small section on news about the ecosystem.
We are very excited to see some project build upon Compose for Web.
Here are the most recent contributions announced at #compose-web channel:
- Compose Chrome extension template by @theapache64
- The experimental routing library for compose-web by @hfhbd
Thank you, #compose-web community!
0.5.0-build225
Add missing embedded HTML elements (apart from PORTAL) IFRAME, OBJECT, PARAM, PICTURE, SOURCE see https://developer.mozilla.org/en-US/docs/Web/HTML/Element
0.5.0-build224
v0.5.0-build224 Update artifact version in web tutorial to 0.5.0-build222
0.5.0-build223
v0.5.0-build223 Update artifact version in web tutorial to 0.5.0-build222
Compose For Web 0.5.0-build222
We've aligned our versioning with the Compose for Desktop
That's why it's 0.5.0-build222! This number should not mislead you - we are still in pre-alpha stage and there's long (but amusing!) road aside.
However from now on there won't be no more confusion cause by differences in artifacts published alongside with Web and Desktop - because there's no more such thing like separate Web publication.
Changes in DOM and CSS API
At early stages we've chosen for CSS interop the CSSOM which is supported in Chrome and for the rest of the browsers we've used polyfill. This actually caused us less troubles than we anticipated (many thanks to the css-typed-om project) however we've decided not to move in this direction. There are three main reasons for this. First, the very nature of this approach requires more dedication for the cross-platform testing. Second, CSSOM per se even in Chrome is not something that is fully implemented and covers everything. Last, but not least, CSSOM for obvious reasons is JS-centric, not all js idioms and design patterns are best fit for Kotlin/JS, and we want to create ecosystem where one will be able to use to full extent all the possibilities Kotlin allows us to use.
That said, we gradually removing CSSOM layer but you most likely won't notice this changes at all - the CSS API users are using mostly hadn't changed so far. Mostly, but there are still things to mention.
Arithmetic operations for homogenous CSS units
Starting from 0.5.0-build222
one can just do something like this:
Div({
style {
val a = 5.px
top(a)
left(a + 2.px)
}
})
You can multiply any numeric CSS unit value by number or you can add and substract values with the same unit.
That said, you can not combine , say pixels and ems - just don't do it ) Right now such attempt will end with quite meaningless result - but we are actually designing the right behavior to deliver you such possibility in next release. Our idea is that in "heterogenous" cases we'll return expression wrapped in calc
.
Simplifying API for setting CSS properties directly
While settings properties (and variables to that matter) in StyleBuilderContext there's no need to make any conversions for Strings, Numbers and CSS Units. We actually had not one but three ways to do that previously - because, you know, three devs are working on Compose for Web ;)
0.0.0-web-dev-14 | 0.5.0-build222 |
---|---|
property("box-sizing", value("border-box")) |
property("box-sizing", "border-box" ) |
property("margin-left", StylePropertyValue(4.px) |
property("margin-left", 4.px ) |
property("margin-left", 4.px.asSylePropertyValue() |
property("margin-left", 4.px ) |
Those are apparently breaking changes but we believe it's obvious why it was justified )
Hopefully in foreseeable future in 99 percent of cases you won't need to write "raw" css properties since API will got it all covered.
Oh, speaking of API we also renamed rem
unit to cssRem
because, as you most probably know, rem is used in Kotlin for different purposes.
Remove possibility to add content to the HTML Elements that are not allowed to have such content
Many, many thanks to our contributor @hfhbd who managed to this week actually contribute three times!
0.5.0-build222
v0.5.0-build222 Update examples to 0.5.0-build221
0.5.0-build221
v0.5.0-build221 Simplify assignment signatures in CSS properties
0.5.0-build220
v0.5.0-build220 Simplify assignment signatures in CSS properties
0.5.0-build219
CSS units API is CSSOM-agnostic and supports homogenous arithmetic op… …erations