Clojurians Log v2
keechma
@mihaelkonjevic I’m looking for the idiomatic way to encode params in URL. How does this look for an on-click handler?
#(ui/redirect
ctx
(merge (:data @(ui/current-route ctx))
{:dates %2}))
Good, that’s how it was meant to be used. If you have a link element you can use ui/url which will return the string that can be used as the href attribute
Yep. And I noticed there is also a pipeline/redirect!--you thought of everything :)
About ui/url: if I’m using the :history router, [:a] links cause a full-on reload. I know libs like accountant (https://github.com/venantius/accountant) short circuit this reload for you--are you thinking of adding something like this to keechma?
Hm, that should be short circuited. History router should add another component around the whole app which catches the clicks. I’ll check today if something broke
@sooheon If you pull and run this example https://github.com/keechma/example-color-panels do you also see the bug where history router causes page reload? I’ve just tried it and it seems to be working correctly for me
That example works fine. But the links are only for route param color (i.e. they are after the ?). The links I have are route level links (just after /, before params).
That shouldn’t matter, so it might be a bug. I’ll double check today and let you know
OK. I can kind-of reproduce it if I add routes key in history-app-definition: :routes [":page"] and another link: [:a {:href (ui/url ctx {:page "foobar"})} "Will Reload"]
It appears to work, but after a bit of clicking around it reloads and shows the figwheel error page
Definitely weird, it might just have to do with how I set up my app.
I could put it up on github if you have the time to look at it?
Yes, please do
ok will ping once I do so
Problem link: https://github.com/DMK-Labs/trendtracker/blob/master/src/cljs/trendtracker/ui/components/header.cljs#L12
@mihaelkonjevic please take a look at the app when you can :)
@mihaelkonjevic I was just about to ask for the ability to modify the route before passing it to params functions, but looking at the commit history I see you just added that - route processors. Thanks for that.
@mjmeintjes yes, I’m not sure if it’s released yet. I can push a new release today if needed
It's not urgent, but I've noticed that a lot of my code is basically just pulling out specific data from the route. I currently have a route namespace with functions for doing that, but having the route pre-processed will clean it up a lot. However I probably won't work on that in the next week or so, so no rush.
I'm working on a new project that will require server side rendering. I noticed that there is an example using Macchiato. Have you used Macchiato in production yet? I'm trying to figure out if it is stable enough to use in a real world app.
We had an rnd project built with macchiato and I didn’t have any problems with it. In my company we’re using elixir on backend so we don’t have any real production experience with it
@mihaelkonjevic I have a question about routing and dataloader. I think of the route as the entrypoint to the app state, so I hooked up a date-range filter in my dashboard to the route (it would put ?dates=2017-01-01,2018-01-01 or something). This allows me to declaratively load data with the dataloader, but it also causes a lot of extra navigation when I press the back button. Rather than going to the last page, it just goes to the last set of params. Is there a way to “squish together” all navigations where only the params have changed, not the route?
@sooheon no, not really. It might be possible (but I’d have to implement it) with the history router, but not with the hashchange one. You could also store those filters in app db instead of the url and then manually retrigger the dataloader. I can make you an example of that if you’re interested
Yes I am interested. I’m trying that method now, and I’m getting mixed up in when dataloaders/controllers retrigger/clean-up data.
I’ll make you an example in an hour or so
Thank you!
@sooheon https://github.com/retro/manually-call-dataloader-example
These are the important parts: https://github.com/retro/manually-call-dataloader-example/blob/master/src/cljs/dataloader_example/datasources.cljs and https://github.com/retro/manually-call-dataloader-example/blob/master/src/cljs/dataloader_example/controllers/filter.cljs
You can manually call (dataloader-controller/run-dataloader!) function from a pipeline after you manually set the value of a datasource
The whole idea of dataloader is that it helps you when possible, but leaves you in control for cases that are not covered by the dataloader