shadaj/slinky

Everything about Slinky -- issues, ideas for features, where it's being used, and more

Peter Storm

@peterstorm

Yeah, but as i said above i want it persisted through page “reloads”, does it do that? As i said, i load alot of profiles up with a search, then i can press one of those profiles to get details. If i the press back in the browser, i want the search result persisted.

The useEffect stuff already works, but it doesnt seem to be persisting

Peter Storm

@peterstorm

I might not have explained it well enough 😅

Gabor Juhasz

@gjuhasz86

can you put the state in an outer layer component? that doesn't change between pages

mcallisto

@mcallisto

The useEffect stuff already works, but it doesnt seem to be persisting

@peterstorm If you want to run an effect and clean it up only once (on mount and unmount), you can pass an empty array ([]) as a second argument. Taken from https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects

Peter Storm

@peterstorm

But thats not exactly what i want, it needs to change with search criterias. And doesnt it get unmounted when you change the page? Or am i misunderstanding something?

mcallisto

@mcallisto

@peterstorm Agreed, in your case you need to store the search results (or the search criteria, if the extraction is fast) somewhere else. Or, depending on the case, you could display the details in a modal within the same component.

Peter Storm

@peterstorm

Does react router have something in the history api or something one could use? It would be fine if it just worked if you pressed back in the browser. But yeah, a modal is a good idea too

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

Where communities thrive

People

Repo info

Activity