This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # alda (9)
- # announcements (1)
- # beginners (6)
- # boot (140)
- # cbus (2)
- # cider (27)
- # cljs-dev (19)
- # cljsrn (17)
- # clojure (104)
- # clojure-art (1)
- # clojure-brasil (5)
- # clojure-colombia (2)
- # clojure-russia (146)
- # clojure-sg (3)
- # clojurescript (64)
- # clojurex (1)
- # cursive (17)
- # data-science (22)
- # datomic (41)
- # editors-rus (5)
- # events (1)
- # hoplon (61)
- # ldnclj (35)
- # lein-figwheel (1)
- # off-topic (1)
- # om (119)
- # onyx (214)
- # re-frame (3)
- # reagent (13)
- # robots (5)
- # slack-help (1)
- # yada (17)
is there a “best practise” solution for this yet? https://github.com/hoplon/hoplon/issues/68
Hi guys. AFAIK now it's possible to define handlers for specific URLs like "/", "/something.html" and "/something/". Is it possible to make custom handler like "/foo/<some-id>"?
In other words — to not to have page (somepage.cljs.hl), for each handler, but make one page expose series of handlers?
if you use pushState you still need to be able to serve the application at all urls in the server
which means either making lots of html files, one for each path, or some kind of shenanigans on the server
that makes, sense, but I'd do it more composable. i.e. having different URL displaying different data one might call "views" abstraction, and URL fragments or "real" URLs (classic reloads and usign pushState would be possibe approaches) would be different implementations for it.
this has sth to do with SEO also, i.e. what does website look like for search engine, not for human users only
@micha: btw, I remember you told me that pushState is somewhat "naïve" in terms of HTTP model. I can't get details on my own yet
btw, how did you manage for source of http://hoplon.io to have actual content?
so we have ring middleware that intercepts those requests and renders the page in phantomjs or htmlunit or whatever
do you plan to implement some built-in support for them? something like "dynamic views" may be?
few things, that I had few times in my projects: 1. List (or may be map, may be set?) of views. And each view is map, that contains few things. 2. Each view is a block inside (body ...) 3. Each view has some API methods associated with it. :get is obligatory it gets it's data from the server when one opens view 4. When one opens view — that's the key point. This is achieved via "on-load" event (for first view that were opened) and by watching route cell as well
and also 5. state cell, that contains some
:view-data in it, which would be returned by
dynamic here means one that uses URL fragments and doesn't do full reload (even any reload)
ok, I'll try to find time to write blog post (and create blog itself, LOL) about what I came up with on that issue. and it would be interesting to see what we have in common and what differs etc
In Javelin CLJS you use
deftype Cell, but in Javelin CLJ you use metadata, is there a reason for this?
looks like mynomoto committed https://github.com/hoplon/javelin/commit/763773f60699a77514bf86e1e92ab8516042d649
...i guess it just wasn't implemented yet, since the tests that test for
#<Cell... presentation were commented out
@andrewboltachev: I have a semi formed solution in place for the views issue as well, currently if you take a look at https://elements.polymer-project.org/elements/iron-pages this is a polymer based solution but it works extremely well and hooked into route-cell with a little jQuery work around. I have a polymer wiki post in progress which ill probably post later today
@bsima: i think hte original reason for the difference was when the clj version was made there weren't ISwap etc protocols, so it wasn't possible to make your own atom-like thing