This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-18
Channels
- # admin-announcements (7)
- # arachne (24)
- # beginners (40)
- # boot (24)
- # braid-chat (22)
- # cider (8)
- # cljsrn (35)
- # clojure (32)
- # clojure-austin (1)
- # clojure-belgium (52)
- # clojure-russia (16)
- # clojure-sanfrancisco (1)
- # clojure-taiwan (2)
- # clojure-uk (25)
- # clojurescript (112)
- # core-async (3)
- # cursive (18)
- # data-science (1)
- # datascript (7)
- # datomic (30)
- # devcards (2)
- # dirac (12)
- # emacs (4)
- # flambo (1)
- # funcool (5)
- # hoplon (146)
- # jobs (9)
- # jvm (5)
- # off-topic (4)
- # om (141)
- # onyx (22)
- # re-frame (89)
- # reagent (86)
- # ring-swagger (31)
- # rum (3)
- # spacemacs (1)
- # specter (10)
- # untangled (112)
- # yada (3)
@levitanong: that's really cool
@onetom: not really, seems like bad error messages are the cost for all the awesomeness of clojure 😕
@alandipert: thanks!
anyone know why loop-tpl
has :bindings
but the other template macros don’t?
loop-tpl
was supposed to work in the HTML form where every attribute has a name which, when compiled, is translated to a key
ok, so why don’t the other templates work that way?
ah, could you give me an example of the two different syntaxes?
um, what about just normally?
well, this is the reason there's a :bindings
key - the above thing gets compiled into (loop-tpl :bindings [x xs] (div ...))
so does for-tpl look like this?
(for-tpl [x xs] (div …))
so is loop-tpl
deprecated then?
@alandipert: can you deprecate loop-tpl
so I can write that in the wiki 😇
would for-tpl
do this?
(for [x ['a 'b 'c]
y [1 2 3]]
[x y])
;;=> ([a 1] [a 2] [a 3] [b 1] [b 2] [b 3] [c 1] [c 2] [c 3])
yeah i could try, just thought you might know
can i get a fact check/review on https://github.com/hoplon/hoplon/wiki/Dynamic-DOM-manipulation-%28Template-Macros%29
i expanded on the good work that was already there and want to make sure i’m not saying the wrong thing
i feel like it's too early to kill HTML support
nobody has used it yet lol
I thought loop-tpl add more arg keys then :bindings
I must be wrong
like dm3 points out above, the reason for the explit kw arg is to be compatible with HTML
yeah.
I see it also has :reverse
key
But yeah, in cljs, not a problem to reverse either
OK, well all I said is that if you’re not using the HTML support, probably stick with for-tpl
as it’s simpler
yeah. i could be on board with deprecating loop-tpl
it's definitely scared clojure people away
heh, just revisited https://github.com/lynaghk/todoFRP/blob/master/todo/hlisp-javelin/src/html/index.html
pre-hoplon hlisp back in the lein days, before even loop-tpl
thing-looper
and tpl
JSX before it was cool
🙂 i was exposed to jsx today again. it's really not cool. i feel like my pinky is starting to fall off. although i haven't typed any, just read it.
@alandipert: Do you have any numbers on html syntax usage for hoplon?
@alandipert: @mynomoto What’s your organizational strategy on the C# app your replacing client code with Hoplon? Do you have separate SPA/hoplon pages for different sections? Do you have one SPA over everything and use app state to determine views? I’m trying to understand how I should approach this in my rails with dozens of models and controllers, but my only experience with SPAs is a couple of CLJS apps I have built and use for one page each on the existing rails apps. Cheers.
and we still have a lot of business logic in the ORM code and API endpoints that needs to be correct when we modify entities in the database
so while we can get huge performance and usability improvements by reading directly from the database and not having an ORM in the castra server, we use our existing API to write to the database to eliminate the possibility of corrupting the database
@levitanong: not really - guessing 0? if anyone's using it they're so happy we've never heard a bug report from them
LISP MASTER RACE 😛
@micha thanks for that. Makes a lot of sense to me. In my own situation, we have separate instances and dbs for each customer so that sort architecture, which would appeal to me with a single instance, would be a nightmare with many. Do you have any suggested strategies? I’m still trying to determine what’s better, one hoplon app that I swap in views based on data/app state or a bunch of smaller, separate hoplon apps. The demo apps you guys have done are great, but I don’t really get a sense of this sort of larger architectural consideration from them.
@jamieorc: i don't think you can go wrong with either approach, as i think you can achieve separation of concerns such that refactoring if you decide you want to try the other option is not too costly
another helpful thing about hoplon apps is you can have two separate approaches running simultaneously
@micha cheers. Some good ideas. Is there a switch to turn off compiling jQuery directly into each hoplon app, or modularize compilation for production? I’ve done this with the Om and re-frame apps. I can then load only the necessary parts into whatever master html page is used.
@jamieorc: i think you can :exclude
jQuery from hoplon by doing :exclusions [cljsjs/jQuery]
in your build.boot, for the hoplon dep
re: modular builds, all the boot-cljs stuff applies
i'm not up to date on it but i believe modules are supported these days
Thanks both. Very helpful and gives me more confidence on the direction I’ve been heading, though mostly I’m just experimenting and playing around right now to get familiar. Fantastic libs you have written.
@alandipert: i’m not using html syntax now, but i have used in the past on some non-trivial projects. One thing now is that I’m using defelem much more now, which iirc couldn’t be done in html syntax. I still think html syntax could be still very useful in a very simple way for non-programmers to just build a substrate for including all the defelems that do the real work
@raywillig: cool. also, being html compatible means being compatible with other markups that compile to html
like whatever the du jour minimal-syntax markup is
@alandipert: Not finding where to place :exclusions [cljsjs/jQuery]. Where does that go? My attempts are either ignored or throw ns errors
@jamieorc: sorry, that's a lein/boot thing
e.g. (set-env! :dependencies '[[hoplon "6.0.0-alpha14" :exclusions [cljsjs/jquery]]])
so there is an explicit dependency
seems like maybe boot-hoplon should take an option, whether or not to add that require to emitted ns-decls?
vs. depending on it in hoplon.core
yeah the case is when you have your own jquery you want it to use
in the embedded scenario
how about an option on boot-hoplon? whether to build jq in or not?
i guess there are really 2 reasons to do it
to save download time, and to deconflict w/ another jq
what about jq's deconflict stuff
the scenario is you are embedding a hoplon app in a page that already has e.g. jq 1.x
and you want your hoplon hole to run its own jq 1.y
but maybe the version that's there isn't compatible with hoplon
i'm thinking use the jq no conflict stuff so that we can guarantee our jq will work wherever you run
right
which i think is totally cool
hoplon/jquery even
if you want to compile your app against jquery but not actually include jquery you would need to have some kind of dependency scope thing i think
yeah that mitigation seems more on the avoiding double download side of things
which isn't as high a priority for most people imo
anyway, any website that's making money is running at least 2 versions of jq 😉
Sound reasoning. It’s not a huge deal to my use case—seemed like, why download this thing more than once? But a solid dependency mechanism is more important than the extra 35kb, or whatever it is.
colocating N apps in the same runtime, basically
it's gonna get interesting
true - i guess we don't have a way to force plugins to take our jq version