Happyx support

[quimt]

Created nbHappyxCode block and internal happyxRoutes for supporting the happyx framework.

Simple helloWorld:

  nbHappyxCode:
    let num = 4
    happyxRoutes:
      "/":
        for i in 1..num:
          tDiv(style="color:red;"): "Welcome to HappyX! "

[HugoGranstrom]

Hi, this looks really cool! I haven't looked too much into HappyX but it seems nice :D So thank you for contributing to nimib. :D

The CI error is unrelated to your code, so don't worry about it :)

The question is if this belongs in nimib or in nimibex. Or plan is to eventually move all non-core features to nimibex (for example nbKarax, nbPython). The two options are that either you open a PR to nimibex and close this one, or we merge this here and later when we have decided on how to do with nimibex we will move it over manually. @pietroppeter which one do you think we should do?

[HugoGranstrom]

The CI should be fixed now, so now you can merge our main branch into your and push it.

[quimt]

Alright, I'll work on pushing through the main branch. Go ahead and migrate to nimibex along with the Karax support. The supporting code for HappyX and Karax are in the same place, and are the same kind of thing, so can be treated the same way.

[HugoGranstrom]

Ah, no I was a bit unclear 😅 Merge our main branch into your happyx-support branch.

[quimt]

It is merged

[HugoGranstrom]

Great! Would you mind adding a simple example at the bottom of interactivity.nim? :D

[quimt]

Thanks for asking! I'll work on getting an example pushed . Should this be in a separate PR?

A near term goal was to do some documentation of the front end for happyX. Nimib is great for teaching and documenting the Nim ecosystem. Thanks for helping to develop and maintain this space!

[HugoGranstrom]

Thanks for asking! I'll work on getting an example pushed . Should this be in a separate PR?

Awesome! :D You can add it in this PR 👍 It doesn't have to be anything fancy, you could even just do the same thing as the other examples in interactivity.nim but in HappyX.

A near term goal was to do some documentation of the front end for happyX. Nimib is great for teaching and documenting the Nim ecosystem. Thanks for helping to develop and maintain this space!

That's exciting to hear that you want to use nimib for documentation :D It's knowing these kinds of things that keeps us excited to evolve nimib into something even better so everyone using nimib can benefit from them 🤩

[quimt]

Alright, I've commited an example. The current implementation doesn't perfectly match HappyX's interpetation of event handler blocks like @click:. My recommendation is to use parentheses to declare the call unambiguously, which have been doing with the pushed content in personal use. This is good enough for now, but another commit may be coming if a satisfactory solution is implemented.

[pietroppeter]

Hi, thanks this looks really nice! happyX looks very cool from a very quick look.

The question is if this belongs in nimib or in nimibex. Or plan is to eventually move all non-core features to nimibex (for example nbKarax, nbPython). The two options are that either you open a PR to nimibex and close this one, or we merge this here and later when we have decided on how to do with nimibex we will move it over manually. @pietroppeter which one do you think we should do?

it definitely belongs to nimibex but I do not seem a lot of harm on having this here and moving it later.

[pietroppeter]

Thanks for this, this is really nice. Also the macro code is really clearly written. I have added a few questions but these are just questions about HappyX which I know very little about (is it happyx or HappyX? should we strive to be consistent? I do agree that nbHappyxCode looks better than nbHappyXCode - which looks like a Mac OS thing... well luckily thanks to style insensitivity we do not really need to take a decision and as it is now is fine by me...)

[pietroppeter]

is this "/" necessary or we can have a template which is just happyxroot? I do not really understand how happyx mixes the server and client side stuff (have not really studied how it works), I understand that routes are fundamental server side, but on the client side and in nimib should we really support them? shouldn't this be always the root in nimib? maybe there are some other use cases I do not know about (like supporting url parameters, which would be cool).

[quimt]

It would be good practice even if having root as "/" were not necessary. appRoutes declares routes -- By default we want to always start by loading the content at #/. Since we could alsohave other routes, so starting a "/" block keeps you mentally prepared to write the others with the same indentation. We could adapt the API to allow for a simplified option for the syntax but since nimib plays nice with the front-end routes of happyx, it's great to have the ability to use them in the nbHappyxCode . This serves most of your needs for switching between very different versions of the DOM:

     let x = 3.14
    nbHappyxCode(x):
      var message = remember fmt"pi is roughly {x}"
      happyxRoutes:
        "/":
          p:
           {message}
          tButton:
            "Click me!"
            @click(
              message.set("gonezo"))
          tButton:
            "Change world"
            @click(
              route("orange"))
        "orange":
          tDiv(style="color: orange;"):
            "Welcome to orange world."
            tButton:
              "Go back"
              @click(
                route("/"))

As you might expect, there are ways to avoid using routes on the front end if you need to, but they can be tedious and error-prone in practice. Imagine creating custom components and templates to manage a complete change of the DOM along with updates to relevant variables in Karax. Routes also give nice feedback to the user in the URL and allow them to bookmark the page with some of the intended state -- note that you can use the ...#orange URL to navigate directly to orange world. I'm not sure of the roadmap toward supporting url parameters on the back-end.

Since happyx already supports the routing syntax on the front-end and back-end, why not use it? This will make working with the full stack more streamlined, and is great for something like switching between a thumbnail index and an in-depth view of some isolated part. Nimib at the very least should be able to demonstrate what we can do with happyX. But nbKaraxCode and nbHappyxCode are useful precisely because sometimes we need to get the formatting and behavior 'verbatim' from the way it is implemented in another SPA.

[quimt]

I do see some potential collisions in the routing of multiple nbHappyxCode instances. I haven't reached that use case yet, and for me it is not critical to have it. A practical rule of using 1 SPA app per webpage in development helps to keep the code readable and avoid errors, in my opinion.

[pietroppeter]

ah ok, I did not realize that frontend routes in happyx are implemented using html fragment identifiers. TIL this is called hash-based routing. having understood this, I think it is definitely appropriate to leave nbHappyxCode as it is.

[pietroppeter]

as another question of differences between happyx and karax, in nbKarax we have a postRender template, how would that work in happyx?

[quimt]

That is one of the features yet to be developed, I believe. I agree it's an area for growth in terms of front-end support.

[HugoGranstrom]

The CI error is because we don't have HappyX installed. You will have to add it to the testDeps tasks in the nimble file.

[quimt]

Updated nimble file.

[pietroppeter]

thanks, all good for me, sorry for the delay in the review! if @HugoGranstrom does not have other remarks/requests, I am happy(x) to merge this!

[HugoGranstrom]

Looks good to me 😁👍

[pietroppeter]

thanks again @quimt for your work on this!

[pietroppeter]

(plan is to finalize the other PRs and make a release where this will be made available)