Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 22 05:59

    shadaj on main

    Update sbt-scalafix to 0.10.0 (… (compare)

  • Jun 22 05:59
    shadaj closed #564
  • Jun 22 05:59

    shadaj on main

    Update sbt-sonatype to 3.9.13 (… (compare)

  • Jun 22 05:59
    shadaj closed #571
  • Jun 20 23:43

    shadaj on main

    Have Scala Steward always updat… (compare)

  • Jun 20 23:40
    shadaj synchronize #536
  • Jun 20 23:40

    shadaj on main

    Update sbt-idea-plugin to 3.13.… (compare)

  • Jun 20 23:40
    shadaj closed #565
  • Jun 20 17:40

    shadaj on fix-docs-ssr

    (compare)

  • Jun 20 17:39

    shadaj on main

    Fix docs SSR unnecessarily depe… (compare)

  • Jun 20 17:39
    shadaj closed #572
  • Jun 20 17:16
    shadaj opened #572
  • Jun 20 17:16

    shadaj on fix-docs-ssr

    Fix docs SSR unnecessarily depe… (compare)

  • Jun 04 19:24
    shadaj commented #569
  • May 24 20:12
    scala-steward opened #571
  • May 24 16:42
    evbo commented #330
  • May 19 13:48
    evbo commented #196
  • May 13 10:51
    scala-steward closed #542
  • May 13 10:51
    scala-steward commented #542
  • May 13 10:51
    scala-steward opened #570
mcallisto
@mcallisto
@peterstorm Honestly I have not explored this avenue... I am thinking you could have the search criteria as a prop for the search page and maybe (but maybe not) do something in the history like you arrived with an empty prop but you left with a prop based on your last search. Just thinking aloud, could be a stupid idea.
Anyway it is not viable for storing the results.
Alexis Hernandez
@AlexITC

for example, you can have your normal service that invokes your API, and another implementation depending on such service but handling the cache

@peterstorm this is what I would do, if you use the router, going back doesn't actually refresh the app state, hence, the cache should be live, or you could go hardcore and cache on indexeddb/localstorage, at the end, it is just sharing the same instance on the app's lifecycle

Peter Storm
@peterstorm
But doesnt going away from a page unmount the componenet, and thus all the state? So if I have a list of 10 profiles, press a profile to see a detailed view, then the state of the profile search will be unmounted right? So router shouldn't work there, right?
anyway, ill test it out :D
A different question, sorry, still a noob here :D
I want a prop that takes a type of List[A], but I can't seem to get it to work. Is it possible? It complains that it can't find the A in the Props of the FunctionalComponenet. And I can't give BasicTable a type parameter, that complaines too
```
@react
object BasicTable {

    case class Props[A](tableData: List[A], tableHead: List[String])

    val component = FunctionalComponent[Props[A]] { props =>

        Grid(className := "tableResponsive")(
            table(className := "tableWrapper")(
                thead(className := "tableHead")(
                    tr(className := "tableRow")(

                    )
                )
            )
        )

    }
}
Alexis Hernandez
@AlexITC

But doesnt going away from a page unmount the componenet, and thus all the state? So if I have a list of 10 profiles, press a profile to see a detailed view, then the state of the profile search will be unmounted right? So router shouldn't work there, right?

That's why the same cached states should be propagated to all components depending on such data, it should work, where it wouldn't work is when you reload the page, or a new tab is opened

I haven't been able to get generic types used smoothly and had to recur to inheritance, like here
Peter Storm
@peterstorm
Ah gotcha
Thanks
Gabor Juhasz
@gjuhasz86
Is there a way for functional components to expose methods for their parents? I just finished rewriting all my components to functional, and realized that the next step requires this.
Alexis Hernandez
@AlexITC
that's against react good practices,isn't it? I suggest to came up with a better design
Gabor Juhasz
@gjuhasz86
yeah, it just seems like however I try, encapsulation in general is against react's good practices
Alexis Hernandez
@AlexITC
I think that's part of the unidirectional-flow design, if you post what you are trying to do, or a code sample, I can try to come up with an alternative approach
Gabor Juhasz
@gjuhasz86
Thanks, I'm working on a small scale example, almost finished
Gabor Juhasz
@gjuhasz86
@AlexITC Ok I think I have something
https://scalafiddle.io/sf/A6u6PzL/0
so we have the component Panel that can do some operation on two numbers
This is self contained and works as expected.
Now I want to create a bunch of Panels and define linkage between them (dynamically), so that the one panel's output is piped to the other panel's first input.
Alexis Hernandez
@AlexITC
Without looking at the code, this is what I'd do, for each panel, define a function that gets invoked when the panel is updated, which you take from the parent component to update other panel's props, which would trigger such panels to be rendered again
Gabor Juhasz
@gjuhasz86
so basically you're saying that I should hold all the state of the panels in the parent, and pass them as props
and whenever I want to update them from inside the panel, I should invoke the callback, provided by the parent
Alexis Hernandez
@AlexITC
yes
Gabor Juhasz
@gjuhasz86
right, that's where I get suspicious about encapsulation.
Because it's not just the state itself, but also all the logic of how to modify it has to be lifted up to the parent. And I will end up with all the state and all the logic in the outermost component.
Not to mention the "loop" which is another pain point, I don't like the index-based addressing even in this solution
Alexis Hernandez
@AlexITC
you could propagate some state through the props to the panels, and each panel can choose if it is worth to do anything, instead of keeping the logic on the parent
Gabor Juhasz
@gjuhasz86
right, that's true
Gabor Juhasz
@gjuhasz86
ok then looking at this from a bit of a different angle: is there a way to keep the state in the parent, pass it to the children as props, but when the children wants to change it, it wouldn't have to call back to the parent who has to provide the exact way of how to change the state?
Gabor Juhasz
@gjuhasz86
I have the feeling that maybe its possible with redux... But I'd like to avoid spending another 2 weeks on a dead-end, so I'm interested in any suggestion
Alexis Hernandez
@AlexITC
I know two ways, you send the argument, or how to retrieve it, in the later case, you can share an object holding a var, which can be mutated, but I think that's a worse idea
Gabor Juhasz
@gjuhasz86
can you show me an example for "sending the argument"?
Alexis Hernandez
@AlexITC
just send such argument in the panel's props
Gabor Juhasz
@gjuhasz86

I mean I can do something like this:

val (nums, setNums) = useState(List((1,2),(3,4)))
nums.map{ p=> Panel(p) }

so far so good, but then I'd like each Panel to be able to change its own props

but that gets messy
Alexis Hernandez
@AlexITC
I'd invoke the useState on each panel's mutable state, and invoke the props callback when such state gets updated
Gabor Juhasz
@gjuhasz86
I'm sorry I don't see how that achieves what I want/ But anyways, it's late, I might give it another try in the morning (not too optimistic, though)
thanks for your help
Peter Storm
@peterstorm
Does anyone have an example with the ContextAPI in SLinky?
Gabor Juhasz
@gjuhasz86
So I was finally able to hack around the problem I had with calling into functional components. I'm passing in an observable using scala.rx. I guess it's still a hack but I didn't feel like rewriting the whole app again in a different framework.
Here's the code from before reimplemented with functional components and scala.rx in case anyone's interested: https://pastebin.com/DnLHpnZ8
Peter Storm
@peterstorm
Hmmm, cant seem to get useContext to work, when doing this:
package connect.ui.components.auth

import slinky.core._
import slinky.core.annotations.react
import slinky.web.html._
import org.scalajs.dom
import slinky.core.facade.{Fragment, ReactElement}
import slinky.web.ReactDOM
import slinky.core.facade.React
import slinky.core.facade.Hooks._
import typings.reactRouterDom.{ components => router}

import scala.scalajs.js

import connect.ui.domain.authentication.Auth
import org.scalablytyped.std.global.console


@react
object AuthContextProvider  {

   val authContext = React.createContext[Auth](Auth(false, "", "", 0, () => ()))

  case class Props(test: String, children: ReactElement*)

  val component = FunctionalComponent[Props] { props =>

    val (isAuthenticated, setIsAuthenticated) = useState(false)


    def loginHandler(): Unit = {
        console.log("loginHandler called")
        setIsAuthenticated(true)
        router.Redirect(to = "/")

    }

    authContext.Provider(value = Auth(isAuthenticated, "", "", 0, loginHandler _))(
        props.children
    )

  }
}
If i then useContext(AuthContextProvider.authContext) in a different component
It only uses the initial context i provided
But if I do AuthContextProvider.authContext.Consumer( context => ...) it works
Peter Storm
@peterstorm
I tried to use it in the App componenet, but that didnt make too much sense
So apologies, it works perfectly well in nested components :)
Sina
@sinaghaffari
Any alternatives to slinky-styled-components since that hasn't been released for Scala 2.13?
Peter Storm
@peterstorm
Does Slinky support React.lazy and Suspense?