and looks like I've missed part about
HasModelPropertyCreator; I can play with it later this week
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.
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
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.
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.
@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
@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 :)
@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:
Hey, I'd like to share two things about
udash.g8:- I've created a PR to update it :) Can I ask someone to review and maybe merge? UdashFramework/udash.g8#26
- 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.
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
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.
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 :)
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
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
Regarding worker: I'll work with it a bit more and as soon as I understand clear API, I'll move forward.
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
Yeah, that sounds like something it would be useful for, cool that it works in your case. Might be simpler than running the workers.
@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.
The main issue that I see right now that
MainServerRPC shouldn't return any Future.
@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): SecureRpcthen 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
But this is a sort of nitpicking, and
Await is more than fine for now
@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
@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.
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
Hello everybody, any plan to release the 0.9? why it's still on Milestore? and what about scala 3, it will be supported?
@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