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

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…

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

This is part 2 of a series of articles about modularizing Android app. If you haven't yet read the first article, you may find it here.

On our first article we just moved some classes outside the application and applied as an independent module. But what if we have dependencies pulled from the application level? This could be a small challenge. First of all, we want to clarify on how are we going to modularize the app. And depending on the previous article, I chose the by feature version of modularization. First of all, let's show some dependencies that are going to be needed in the whole app.

Note: I'm using Dagger for handling dependencies but manual DI or any dependency tool should be fine to understand this part.

So, this is my dependency schema:


Well, it's not that bad, but this isn't what we want to transform to when trying to modularize the app. If you think about it, modules that don't need a dependency, can get it quite easily. For example: A FeatureXVi…