https://kotlinlang.org logo
Join Slack
Powered by
During my research for some open source projects u...
# javascript
m
During my research for some open source projects using the IR compiler I stumbled upon the kotlin-full-stack-application-demo and noticed that the project diverges from the IR compiler migration guide in some points: Example from Post.kt view: • Booleans are not nullable in 
PostState
although the migration guide lists this as a migration step • Initialization of the 
PostState
is done by assigning an 
object
derived from 
PostState
to the 
state
in the 
init
block, but IntelliJ shows a warning that this 
object
should be an 
external interface
to tell the compiler that this is no Kotlin object as described in the migration guide Are there other open source JetBrains projects (or just other projects in general) that already use the IR compiler to get some insights on how this more restrictive design is handled in these projects?
t
You can use this example
And this
And about warning for 
Boolean
. Required boolean property is fine.
External props - helpful inspection
m
Thank you for these helpful resources!
@Boolean warning: Do you mean that it’s not necessary to make booleans nullable in external interfaces or what do you mean by that
t
It depends on your use cases. If you have required parameter - it must be non-null
In my cases optional property - exception. Usually properties are required and non-null.
That is why I don’t use this inspection
In MUI we have required boolean properties and it’s normal
m
We are using class components instead of functional components where we define props and states like 
external interface MyState : RState { var myBoolean: Boolean? }
Having to make all booleans nullable in 
MyState
adds an extra layer of complexity because it either requires to force unwrap the boolean for every usage or putting all state members in a separate class which is then put in 
MyState
like 
external interface MyState : RState { var myClass: MyClass }
& 
class MyClass(var myBoolean: Boolean)
Any ideas on that part? (Still referring to the IR migration guide)
t
Usually I use “unsafe boolean” strategy in such cases
undefined
like 
false
m
So how would that look like then? E.g.: 
if (!someBoolean)
would currently need to look like 
if (someBoolean != true)
when changing it to be nullable
By overriding the not operator?
t
I use non-nullable booleans (“unsafe boolean”)
m
Oh, now I get what you mean - thank you!
v
@turansky isn’t “unsafe boolean” a thing that needs to be removed when updating to the IR compiler? See https://kotlinlang.org/docs/js-ir-migration.html#make-boolean-properties-nullable-in-external-interfaces
t
It’s definitely has no sense in case of required boolean properties - we have such cases in 
kotlin-wrappers
project In my project I use it even for optional properties, when 
false
by default is fine. It’s unsafe, but it’s less code and more readability @Sergei Grishchenko
s
Moritz Hofmeister  [3:31 PM]
@Boolean warning: Do you mean that it’s not necessary to make booleans nullable in external interfaces or what do you mean by that
Victor Turansky  [4:40 PM]
I use non-nullable booleans (“unsafe boolean”) (edited)
I totally agree with @turansky, in case of Kotlin/JVM integration, developer decides whether value received from Java code is nullable or not, I think the same strategy should be used in case of Kotlin/JS integration too, only developer should decide his Boolean is nullable or not, in my point of view forcing everybody to use nullable booleans is big mistake
👍 3
v
Ok, thanks for the info. Shouldn’t the wording at https://kotlinlang.org/docs/js-ir-migration.html be then updated? Because currently it reads more like “you need to do those things when migrating to the IR compiler. And isn’t then the IDE-inspection also somehow misleading?
t
Feel free to vote
4 Views
Open in Slack
PreviousNext
Powered by