https://kotlinlang.org logo
Join Slack
Powered by
<@U33H6SB2B>, continuing our discussion on kfc-plu...
# react
m
@turansky, continuing our discussion on kfc-plugins.
JFYI - Seskar adds component names automatically for dev builds 😉
Already including this dependency. Not sure how this impacts? Replacing emotion.react.css with a placeholder class still generates 
Exception during run: SyntaxError[ @<.../app>.mjs ]: Identifier 'set' has already been declared
in my full app. I don't know exactly what that indicates. Maybe something else (mui?) is pulling in the problem code transitively?
Copy code
package emotion.react

import react.FC
import react.Props
import web.cssom.AlignItems
import web.cssom.Color
import web.cssom.Display
import web.cssom.FlexDirection
import web.cssom.FontWeight
import web.cssom.JustifyContent
import web.cssom.Length
import web.cssom.TextAlign

external interface PlaceholderCssProps : Props {
    var background : Color
    var color : Color
    var fontWeight : FontWeight
    var textAlign : TextAlign
    var display : Display
    var flexDirection : FlexDirection
    var alignItems : AlignItems
    var gap : Length
    var justifyContent : JustifyContent
}

val css = FC<PlaceholderCssProps>("placeholder-css") {

}
t
Already including this dependency. Not sure how this impacts?
No needs to write: 
val MyComp = FC("MyComp") {}
you can write 
val MyComp = FC {}
name will be added by plugin 😉
👍 1
Component 
css
- your own component?
Looks like cool plan to break compiler 😉
m
That was a temporary placeholder so I could remove the kotlinWrappers.emotion.styled dependency and still compile.
Otherwise I would have had to rewrite hundreds of lines of code
t
so I could remove the kotlinWrappers.emotion.styled dependency
Why it's required?
m
In my simplified project, removing the kotlinWrappers.emotion.styled dependency got rid of 
Exception during run: SyntaxError[ @<.../app>.mjs ]: Identifier 'set' has already been declared
but by that point, I'd already gotten rid of many other dependencies as well
kotlinWrappers.emotion.styled is used by one of our developers for styling?
t
I mean "why removing required"
m
In the simplified project, removing kotlinWrappers.emotion.styled dependency removes 
Exception during run: SyntaxError[ @<.../app>.mjs ]: Identifier 'set' has already been declared
So I was trying to see if that was full reason in the full project having 
Exception during run: SyntaxError[ @<.../app>.mjs ]: Identifier 'set' has already been declared
t
And it's only problem in tests? Right?
m
Problems building tests, yes:
Task :jsTestClasses
Task :kotlinStorePackageLock UP-TO-DATE
Task :compileTestDevelopmentExecutableKotlinJs
Task :jsTestTestDevelopmentExecutableCompileSync
Exception during run: SyntaxError[ @/home/mkienenb/IdeaProjects/gvea/performance-appraisal-frontend/build/js/packages/performance-appraisal-frontend-test/kotlin/performance-appraisal-frontend-test.mjs ]: Identifier 'set' has already been declared
t
At which point you faced this problem?
Was it fine when you used Webpack?
m
Yes, this only happened when I added vite support via kfc-plugin One other thing I could try is to see how 
useEsModules()
without vite affects the project, assuming that works.
I had to make a number of other changes to get vite working
t
target = "es2015"
- meta flag
At the same moment in your example for Kotlin Wrappers you don't have such problem?
m
No, everything is fine without vite/es modules
t
1. We use example 
target = "es2015"
in examples 2. Vite isn't used in tests (even with KFC)
m
My KW test example doesn't use emotion or mui, though
It is definitely related to emotion, and possibly mui considering the mui errors I got with dev.opensavvy.vite.kotlin's plugin
t
You can add 
emotion
in test and check if everything is OK 😉
And align configuration if it's OK in wrappers tests
m
yes, I know I can. That may be my next step. But there's only so much I can do in one day. Finishing up the test router example now. Then back to paying work later. :)
I can also upgrade the example to use vite 🙂
t
It will not affect test logic (if yes it will be big surprise). KFC use Vite for 
main
run and build only.
m
Definitely affects the test build. To be determined if it will affect the test run since I can't get it to that stage yet 🙂
t
It applies common compiler configuration. If it affects tests somehow - it should be fixed in Kotlin.
And Kotlin configurations of Kotlin Wrappers and KFC synchronized 😉
m
The tanstack jsNodeTest example PR is finally out there: https://github.com/JetBrains/kotlin-wrappers/pull/2840
t
Cool!
Thank you!
Comments are ready! ;)
m
All changes are in. Let me know if there's anything I missed.
t
We need name, which will describe problem 😉 
append-jsdom-to-user-agent-name.js
And comment about problem source
For all new tests we use readable names:
Copy code
@Test
fun `check record size`() {
}
Please use it too.
@Mike Kienenberger please send us link on "Redundand user agent configuration for 
jsdom
run" coroutines issue, when it will be created 😉
s
@Mike Kienenberger thank you a lot for your test example for 
testing-library
, it looks awersome. I have one question about it. I noticed that almost after each 
findByTestId
query you use 
assertNotNull
check. I thought that semantic of 
findByTestId
says: "I will wait till element appears on the screen and then I will give it to you". So in this sense I don't see a scenario where it can return 
null
. As far as I can understand it either returns element or fails with timeout. But maybe I don't see some edge case or behavior of this helper is different. So my question is: is 
assertNotNull
is required or not for this kind of test? and if yes - why?
m
No, you are completely correct. That test was copied from a different project and then pruned down. Some of the choices are not optimal. 😀 I've submitted a PR to remove the asserts after 
findByTestId
and to replace some of the 
findByTestId
with 
queryByTestId
when there is no render expected between the statements. The test is also a little boring. At some point maybe I will have time to make it more interesting.
😜 1
👌 1
thank you color 1
t
@Mike Kienenberger will you create issue on Coroutines (about redundant user agent manipulation)? We need it for PR ;)
m
I really need to add either a useEffect coroutines launch or a kotest example to the router example because what I have so far doesn't demonstrate the problem. I could report it without a reproducible example, but that's Less Good. Back in KW 2026-12.* and kotest 6.0.0M3, I could reproduce it in kotest by using more than 16 empty test classes. In kotest 6.1.3, that changed to require 15 or more tests in the same test class, and probably also required either triggering a useEffect or an RTL.act or a ktor httpclient.get(), so it got harder to reproduce in a simple example. And it's not so much about redundant user agent manipulation as it is about lack of a public API to set the NodeDispatcher. The user-agent manipulation is just the hack that's currently required.
Normally I have free time Thurs and Fri mornings and saturdays, but this is an extra-busy week for me, so it might be 10 days before I have time to put it all together
@turansky, I'm updating the test example to include dependency injection (no external library) and scope.launch inside useEffect. That not only makes the code more interesting and realistic, but it should be the next step to getting coroutines reproducible example ready. Creating a PR now. For the life of me, I can't figure out how to get Intellij to perform code analysis on the code inside 
examples
. About the only thing that works on that code is 
extract method
-- the IDE never shows any warnings or errors, and I have to pick them up from running the code and checking the output. Everything at the main project level works fine.
t
You can call context menu at 
examples/build.gradle.kts
and select 
Link Gradle Project
option 😉
m
That was my issue! Thanks.
Now that the test example has IDE support, I see one odd situation. The tests all compile and run, but the IDE itself reports the following as errors. Interface 'interface CreateMemoryHistoryOpts : Any' does not have constructors. Interface 'interface RouterOptions : RouterOptions<RootRoute>' does not have constructors.
t
It's IDEA bug - we need issue for likes 😉
And issue for coroutines too 😉
m
All of this was a step toward getting the coroutines issue 🙂 I have many pending 3rd party issues: • coroutines dispatcher • kotest (3 in progress) • selenium (1 in progress)
I probably have 5 or more IDEA issues that I just will never get to 🙂
I'm drowning in issues 🙂
t
Coroutine's issue I know how to fix 😉
m
t
Is it second Coroutine's issue?
m
Just pushed out a change to that. I forgot to comment out the script that changes the user agent. Almost done drafting the coroutines issue for submission.
t
I would say 
NodeDispatcher
should be used on Node.js without additional questions/configuration 😉
m
I didn't want to suggest a change that would break backward compatiblity, but I agree that makes the most sense
t
I didn't want to suggest a change that would break backward compatiblity
It's bug fix 😉
I should't save bugs 😉
m
I guess I'm not sure if that's actually true. I can't be sure what use cases other people are using in kotlin/js with coroutines. If it were only a bug, why didn't they just check for the existence of process.env?
t
process.versions.node
check - current draft solution
m
To me, that seems like the right approach, but I don't feel knowledgeable enough to assert that
A search of slack shows a lot of code using process.versions.node. But even if that's the right way to detect node, it may not be the right way to determine if the NodeDispatcher should be used
Victor, if you have a more compelling justification as to why say 
NodeDispatcher
should be used on Node.js without additional questions/configuration, now would be a great time to add it to the issue. ;)
thank you color 1
3 Views
Open in Slack
PreviousNext
Powered by