Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 23 12:05
    ddworak review_requested #986
  • May 23 12:03

    ddworak on master

    Update scala-logging to 3.9.5 Merge pull request #985 from sc… (compare)

  • May 23 12:03
    ddworak closed #985
  • May 23 12:03

    ddworak on master

    Update client3:async-http-clien… Merge pull request #984 from sc… (compare)

  • May 23 12:03
    ddworak closed #984
  • May 23 12:02

    ddworak on master

    Update circe-core, circe-parser… Merge pull request #983 from sc… (compare)

  • May 23 12:02
    ddworak closed #983
  • May 23 12:02
    ddworak milestoned #981
  • May 23 12:02
    ddworak assigned #986
  • May 23 12:02
    ddworak opened #986
  • May 23 11:59

    ddworak on nested-multi

    Clean multiple bindings (compare)

  • May 22 15:13
    dsabanin starred UdashFramework/udash-core
  • May 21 20:00
    scala-steward opened #985
  • May 20 11:20
    scala-steward opened #984
  • May 20 05:33
    scala-steward opened #983
  • May 13 09:51

    ddworak on v0.9.0-M33

    (compare)

  • May 13 09:51

    ddworak on generic-nested

    (compare)

  • May 13 09:51

    ddworak on master

    Generic nested interceptor Don't infer return type in inte… Merge pull request #981 from Ud… (compare)

  • May 13 09:51
    ddworak closed #981
  • May 13 09:49

    ddworak on master

    Update scalajs-dom to 2.2.0 Merge pull request #982 from sc… (compare)

Dawid Dworak
@ddworak
@catap can you add an issue regarding Safari in g8?
Kirill A. Korinsky
@catap
@ddworak which repo should I use?
and looks like I've missed part about HasModelPropertyCreator; I can play with it later this week
Dawid Dworak
@ddworak
@catap g8, as I'm not sure if the issue is within core. We'll dispatch later on
Kirill A. Korinsky
@catap
Dylan Arnold
@DylanArnold
So I'm switching from ScalaCSS to UdashCSS and it's great and everything has gone smoothly apart from a couple of css class naming differences from ScalaCSS. The first is that if I have an anonymous class the css class name includes $anon (the $ character is invalid in css class names). The second (larger) issue is that when instantiating a class multiple times (in different ways to generate variants of styles), there are naming collisions since the css class name is generated from the scala class name. ScalaCSS solves both of these issues. For the first issue it strips the $ character. For the second issue it checks for duplicate class names and will append an incrementing number (e.g MyClass-1, MyClass-2). I'm wondering if anyone has come up against this and if there is a reason the udash implementation is different.
Dawid Dworak
@ddworak
Hi @DylanArnold!
I think the name issue is just sth ScalaCSS added later on in the macro part, which unfortunately cannot be fully reused - you can add an issue or submit a contrib to io.udash.css.macros.StyleMacros.
Regarding the second issue - can you show the full example of this (can be in ScalaCSS)? The issue might be that we're treating each class separately for rendering - otherwise we're just using ScalaCSS rendering capabilities directly.
Dylan Arnold
@DylanArnold
@ddworak Thanks for the reply :smile: . I'll try to take a look at the first issue soon. I've created an example project which demonstrates what I mean in ScalaCSS. Happy to dig into this more, or contribute... From what I understand ScalaCSS just keeps track of what class names it has rendered. If it renders them again it will just increment the suffix https://github.com/DylanArnold/scalacss-generated-class-name-example
Dawid Dworak
@ddworak

@DylanArnold oh I understand now, but I'm still not sure I know why you'd want to use it (rendering the same stylesheet twice and expecting different results). What classname should the frontend use then? The intended use case with Udash CSS is for the classnames to be known statically (at compile time), so we can use them in the frontend and only compile styles as regular CSS files on the backend. This saves a lot on JS-code. With ScalaCSS approach you mentioned the classnames cannot be known to the compiler before runtime.

If you really need it, the workaround would be to provide a custom Renderer[String], which might be able to serve a similar role as the cssRegister in ScalaCSS - remember previously rendered class names and act on it.

If there's a use case for a Udash CSS with multiple "instances" case, I'll be happy to help. We could e.g. support inheritance better in the classnames, but I fail to see it enabling anything more than mixins do. I'm not a CSS expert though :)

Dylan Arnold
@DylanArnold
@ddworak I'm not completely sure if we're talking about the same things, probably partly due to my examples and the fact we're talking about two libraries. I do see a few problems based on what you're saying though due to the differences between Udash CSS and Scala CSS. In my codebase I don't actually call render on the same class extending CssBase multiple times. I do however follow this pattern a bit in some cases https://japgolly.github.io/scalacss/book/features/reuse.html However I think it's mostly used for mixins. (These would still translate to single render call). The bigger issue I find is illustrated in my Example 2 and Example 3. Those are the ones where it's a single render but calling a def to reuse code, this is super useful to generate multiple sets/variants of styles. I actually worked around this in Udash CSS by writing my own function which calls namedStyle. I keep an internal counter to deduplicate the class name and then pass the deduplicated name with the counter as the suffix to namedStyle. It works fine but I guess it's relying on the initialisation order of the styles, which should be the val order within the class. This wouldn't work if calling render multiple times since then I see there could be differences between what happens when generating the stylesheet in the backend (with a particular ordering) vs what order the sheets are initialised on the frontend (which could be a different ordering). In my frontend project I should have an explicit initialisation order though since I register all my styles in a specific order and there are no lazy vals. I don't think there should be any problems unless calling render on the same class multiple times in the backend which I agree would be weird and I don't see a use case for that. I do see that there is a small runtime component to what I'm doing to make this work, but it seems fine as long as the initialisation order is well defined. I may try to get rid of my defs to simplify but they really are easy to understand and conveninent. Either way there isn't an immediate problem as I've got a workaround. Cheers :smile:
Grzegorz Szeremeta
@mereszeta
@DylanArnold you're spot on, our approach for that is using namedStyle
Kirill A. Korinsky
@catap
Hey, I'd like to share two things about udash.g8:
  1. I've created a PR to update it :) Can I ask someone to review and maybe merge? UdashFramework/udash.g8#26
  2. I've created a dedicated branch with example of worker: https://github.com/catap/udash.g8/tree/worker ; I feel that it is a good idea to include it into default code. I feel that it might be and should be heavy refactored anyway.
Dawid Dworak
@ddworak
Hi @catap, thanks for the contribution!
I've proposed a change of approach in your PR, I'll make sure to review again in more detail once we hash that part out.
Regarding the worker template, I think it'd work better as a separate template. Workers are not a typical use case for webapps and I'd like to keep the main template as simple as possible (probably even migrate some of the boilerplate to core). Maybe you could just host it in your own public repo? I'm happy to mention it somewhere in the docs.
Kirill A. Korinsky
@catap
@ddworak I understand, and honestly think that WorkerService (or something like that) should be part of the framework, and not template.
Regarding your point of yes / no: yes, it is good idea. Let me try.
And out of curiosity: how you update g8 template? Right now it seems like a night mare :)
Dawid Dworak
@ddworak
I'm sure it will at some point (probably once there's work in the framework to offload on such worker) :P
It is a nightmare. I usually generate an application, create a git repo and track my changes to the main app, then apply that patch to the template. That's probably why I do it so rarely :D
Kirill A. Korinsky
@catap
I see, the same nightmare that I'm going right now
Regarding worker: I'll work with it a bit more and as soon as I understand clear API, I'll move forward.
Kirill A. Korinsky
@catap
@ddworak thus, do you have any suggestion for tools to create IU / forntend?
My goal is design a few pages to make a sort of MVP to play with one idea. Ideally a way how can I use existed bootstrap template in udash
To be honest: https://getbootstrap.com/docs/4.1/examples/dashboard/ is more than enough
Kirill A. Korinsky
@catap
@ddworak seems that MacrotaskExecutor allows to not use worker for my case: running quite complicated math in a lot of futures
Dawid Dworak
@ddworak
@catap what do you mean by tools? This dashboard looks just like an example / template to me.
Yeah, that sounds like something it would be useful for, cool that it works in your case. Might be simpler than running the workers.
Kirill A. Korinsky
@catap

@ddworak yes, it is much simpler that web worker because I don't need messages and a lot of synchrnozation :)

Regarding template => I've figured it out. No magic, just must invest some time.

Kirill A. Korinsky
@catap
@ddworak do you have any public available example how to mix udash and DB? I can use any ORM or write SQL queries by hand :)
Dawid Dworak
@ddworak
@catap intentionally not, our default which ties nicely with existing serialization etc. is the commons-mongo driver https://github.com/AVSystem/scala-commons/blob/master/docs/TypedMongo.md. Obviously Udash starts at endpoints which are usually not coupled with the DB layer at all, unless the app is really small.
Kirill A. Korinsky
@catap
@ddworak I'm asking it because I'm try to mix udash with slick... well..
The main issue that I see right now that MainServerRPC shouldn't return any Future.
Kirill A. Korinsky
@catap
So, inside ExposedRpcInterfaces I have this hack:
  // TODO: avoid await
  override def secure(token: UserToken): SecureRPC =
    Await.result(authService.findUserCtx(token) map { ctx =>
      secureEndpoint(ctx)
    }, Duration.Inf)
Dawid Dworak
@ddworak

@catap this should only be an issue with auth, right? anyway how I'd do it would be to separate the secure and open API:

trait MainServerRpc {
  def auth: AuthRpc
  def secure(token: UserToken): SecureRpc

then e.g.:

trait AuthRpc {
  def loginWithPassword(username: String, password: String): Future[UserContext]
  def loginWithToken(token: UserToken): Future[UserContext]
}

this way you can even cache the token on frontend etc. and reuse later on

with websockets its common to have multiple small calls as the connection is already established
another approach would be to authenticate the user before MainServerRPC is created
Kirill A. Korinsky
@catap
@ddworak I see your point. But secure is opening a connection to backend which is used as secured connection. The issue that it may go to separated backend and backend need to go to session DB to check that token is valid :)
But this is a sort of nitpicking, and Await is more than fine for now
Kirill A. Korinsky
@catap

@ddworak / @mereszeta I need your help. I don't understand how can I create an RPC endpoint for custom object.
Let assume that I have code:

object AdditionalGenCodecs {
  implicit val instantGenCodec: GenCodec[Instant] =
    GenCodec.nullableSimple(i => {
      val seconds = i.readLong()
      val nanos = i.readLong()
      Instant.ofEpochSecond(seconds, nanos)
    }, (out, v) => {
      out.writeLong(v.getEpochSecond)
      out.writeLong(v.getNano)
    })
}

trait ServerPartyRPC {
  def getMoment: Future[Instant]
}

object ServerPartyRPC extends DefaultServerRpcCompanion[ServerPartyRPC]

it can't be compiled with error like:

Macro at line 23 failed: cannot translate between trait ServerPartyRPC and trait ServerRawRpc:
problem with method getMoment:
 * Raw method call did not match:
   No GenCodec found for java.time.Instant
 * Raw method get did not match:
   scala.concurrent.Future[java.time.Instant] is not a valid server RPC trait, does it have a companion object that extends DefaultServerRpcCompanion or other similar companion base class?
 * Raw method fire did not match:
   real result type scala.concurrent.Future[java.time.Instant] does not match raw result type Unit
  def getMoment: Future[Instant]
Anyway, if I wrap Instant into simple case class I can use HasGenCodecWithDeps which allows to compile code like:
object AdditionalGenCodecs {
  implicit val instantGenCodec: GenCodec[Instant] =
    GenCodec.nullableSimple(i => {
      val seconds = i.readLong()
      val nanos = i.readLong()
      Instant.ofEpochSecond(seconds, nanos)
    }, (out, v) => {
      out.writeLong(v.getEpochSecond)
      out.writeLong(v.getNano)
    })
}

@transient
case class MyInstant(instant: Instant)
object MyInstant extends HasGenCodecWithDeps[AdditionalGenCodecs.type, MyInstant]

trait ServerPartyRPC {
  def getMoment: Future[MyInstant]
}

object ServerPartyRPC extends DefaultServerRpcCompanion[ServerPartyRPC]
I feel that better to move to an issue
Kirill A. Korinsky
@catap
Kirill A. Korinsky
@catap
@ddworak very fast question: how huge scope of work shall be to introduce bi-direction RPC calls? :)
Kirill A. Korinsky
@catap
right now I have the way to overstep it, but if I can enjoy udash RPC, it can be quite nice.
Dawid Dworak
@ddworak
I'm not sure I understand the notion, udash RPC is already bidirectional (both requests and responses go 2 ways). What would be the point of unifying that and how would it differ from a common trait extended twice for client and server RPC implicits?
Kirill A. Korinsky
@catap

@ddworak I need the way to call from backend some function inside frontend and has result.

Let assume that I have a simple interface:

trait Foo {
  def call(someID: SomeID): Future[SomeResponse]
}

My application needs to call call from frontend to has SomeResponse from backend, and a backend needs to make the same: to call call to have SomeResponse from frontend.

Kirill A. Korinsky
@catap
And the next question: is it possible to increase timeout for one, single call?
I have one call which might work for a while. A while means more than 30 seconds. Right now I've increased all timeouts, but it seems like a hack
minettiandrea
@minettiandrea:matrix.org
[m]
Hello everybody, any plan to release the 0.9? why it's still on Milestore? and what about scala 3, it will be supported?
Dawid Dworak
@ddworak
@minettiandrea:matrix.org actually yes, we're not planning any new features in 0.9 (unless they happen to be needed by us or contributed), but we unfortunately haven't found the time yet to finish the guide & docs update :( it's definitely living in my head rent free though
@catap and how that "bidirectional" RPC would solve that any better than just by using server and client RPCs? Technically it wouldn't do anything new, so where's the improvement? Some new syntax? I'll be happy to review a draft issue should you have some idea :D
@catap I can't think of a way to customize the timeout right now other than just timeout manually on the backend / frontend with sth like https://monix.io/docs/current/execution/future-utils.html#timeout-slow-futures