Skip to main content

Getting hands dirty with KotlinJs



Although web development hasn't been my thing since I started programming, I was really attracted the way Kotlin does solve things. So I did give a try to KotlinJS.

This is how to set up a KotlinJs page in less than an hour. 

Note: Chose to use the simplest set up without gradle or maven. You are free to chose what you like.

First of all, you start with a new project in your IntelliJ and choose Kotlin -> Javascript.


After that, you can name your project and start. The IDE will generate an empty folder for you.

So to start of, you have lots of options here, for example, you may program the html and css on your own, and than connect the dots with kotlin. Or, you can fully type in Kotlin (as I chose to do it) with this nice library called Kotlinx Html.
Since I'm not using gradle nor maven, I should import it as a JAR (which is not that cool, but for a demo project, no problem) 👎

On with the show. 
So what the app will do? The user inputs a name, and he gets back a Chuck Norris joke with the name inside it.

And after that: 

The code:

I found a nice implementation using the MVP pattern (not sure if it is the right one on the web) here. So I set up the interfaces first.

After that I create the View implementing class and the Presenter implementer class:

Notice the API call is made with XMLHttpRequest, inside the getAsync method. That's the object responsible for API calls. When response successful, we parse the response to our RandomJokeResponse object and let the view handle the rest.


The HTML tags are not constructed as normally thanks to KotlinxHTML, but they are written in Kotlin(DSL).

But the browser doesn't speak Kotlin! The connecting dot.


It certainly needs an HTML file, with some small configuration. On the scripting tags I connect the generated files inside the out directory and libraries that I might include. At that's all sufficient for the browser. Now you may continue to type KOTLIN. 

After that, you are free to create a class whatever the name is, and write the main method, so that the View page will be constructed. Since I'm a spring fan, I add the `Application` suffix: 



Done! You may check the page here:

Name Norris Joke KotlinJS

And full project on:

Name Norris Joke KotlinJS Repository

Conclusion
Kotlin is the language that brought so innovative ways of solving problems. It's growing and improving every day. You may deal nearly everywhere with it: Android, Server-Side, Frontend and even IOS with Kotlin Multiplatform.

Good luck playing with it.

Popular posts from this blog

What I learned from Kotlin Flow API

I used to check the docs and just read a lot about flows but didn't implement anything until yesterday. However, the API tasted really cool (even though some operations are still in Experimental state).Prerequisites: If you don't know RxJava it's fine. But a RxJava recognizer would read this faster.Cold vs Hot streamsWell, I really struggled with this concept because it is a little bit tricky. The main difference between cold and hot happened to be pretty simple: Hot streams produce when you don't care while in cold streams, if you don't collect() (or RxJava-s equivalent subscribe()) the stream won't be activated at all. So, Flows are what we call cold streams. Removing the subscriber will not produce data at all, making the Flows one of the most sophisticated asynchronous stream API ever (in the JVM world). I tried to make a illustration of hot and cold streams: Since I mentioned the word asynchronous this implies that they do support coroutines also. Flows vs…

Modularizing your Android app, breaking the monolith (Part 1)

Inspired by a Martin Fowlers post about Micro Frontends, I decided to break my monolithic app into a modular app. I tried to read a little more about breaking monolithic apps in Android, and as far as I got, I felt confident to share my experience with you. This will be some series of blog posts where we actually try to break a simple app into a modularized Android app.

Note: You should know that I am no expert in this, so if there are false statements or mistakes please feel free to criticize, for the sake of a better development. 

What do you benefit from this approach:
Well, people are moving pretty fast nowadays and delivery is required faster and faster. So, in order to achieve this, modularising Android apps is really necessary.You can share features across different apps. Independent teams and less problems per each.Conditional features update.Quicker debugging and fixing.A feature delay doesn't delay the whole app. As per writing tests, there is not too much difference about…

From Gson to Moshi, what I learned

There is no doubt that people are getting away from GSON and I agree with those reasons too. The only advantage GSON has over other parsing libraries is that it takes a really short amount of time to set up. Furthermore, the most important thing is that Moshi is embracing Kotlin support.

First let's implement the dependency:
implementation("com.squareup.moshi:moshi:1.8.0") It's not a struggle to migrate to Moshi. It's really Gson look-a-like. The only thing to do is annotate the object with @field:Json instead of @SerializedName (which is Gsons way for JS representation):

data class User( //GSON way @SerializedName("name") val name: String, @SerializedName("user_name") val userName: String, @SerializedName("last_name") val lastName: String, @SerializedName("email") val email: String ) data class User( //Moshi way @field:Json(name = "name") val name: String, @field:Json(name = "user_name…