Fork me on GitHub
#hoplon
<
2016-05-18
>
alandipert01:05:33

@levitanong: that's really cool

mynomoto02:05:18

@onetom: not really, seems like bad error messages are the cost for all the awesomeness of clojure 😕

thedavidmeister13:05:47

anyone know why loop-tpl has :bindings but the other template macros don’t?

dm313:05:52

loop-tpl was supposed to work in the HTML form where every attribute has a name which, when compiled, is translated to a key

dm313:05:25

HTML support is considered to be dead AFAIK

thedavidmeister13:05:51

ok, so why don’t the other templates work that way?

dm313:05:19

because HTML support is considered to be dead, I think

dm313:05:36

so the new stuff doesn't try to accomodate it

dm313:05:18

I now use for-tpl instead of loop-tpl exclusively

thedavidmeister13:05:56

ah, could you give me an example of the two different syntaxes?

dm313:05:36

<loop-tpl bindings="{{x}}">
   <div>...</div>
</loop-tpl>

dm313:05:40

something like that, I think

dm313:05:42

never used it

thedavidmeister13:05:06

um, what about just normally?

dm313:05:44

well, this is the reason there's a :bindings key - the above thing gets compiled into (loop-tpl :bindings [x xs] (div ...))

dm313:05:39

so HTML attributes are mapped to keywords by the compiler

dm313:05:02

(this is all somewhat informed speculation, as I've never used the thing)

thedavidmeister13:05:23

so does for-tpl look like this?

thedavidmeister13:05:34

(for-tpl [x xs] (div …))

dm313:05:44

ah, you wanted just Cljs

thedavidmeister13:05:01

so is loop-tpl deprecated then?

dm313:05:16

I would deprecate it

dm313:05:23

but then it's up to the higher powers to decide

thedavidmeister13:05:46

@alandipert: can you deprecate loop-tpl so I can write that in the wiki 😇

thedavidmeister13:05:47

would for-tpl do this?

thedavidmeister13:05:50

(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])

dm313:05:39

could you try? simple_smile

dm313:05:00

only ever used it with one binding

thedavidmeister13:05:33

yeah i could try, just thought you might know

thedavidmeister14:05:48

i expanded on the good work that was already there and want to make sure i’m not saying the wrong thing

alandipert14:05:40

i feel like it's too early to kill HTML support

alandipert14:05:43

nobody has used it yet lol

leontalbot14:05:21

I thought loop-tpl add more arg keys then :bindings I must be wrong

alandipert14:05:26

like dm3 points out above, the reason for the explit kw arg is to be compatible with HTML

leontalbot14:05:18

I see it also has :reverse key

leontalbot14:05:50

But yeah, in cljs, not a problem to reverse either

thedavidmeister14:05:41

OK, well all I said is that if you’re not using the HTML support, probably stick with for-tpl as it’s simpler

alandipert14:05:21

yeah. i could be on board with deprecating loop-tpl

alandipert14:05:37

it's definitely scared clojure people away

alandipert14:05:18

pre-hoplon hlisp back in the lein days, before even loop-tpl

alandipert14:05:46

thing-looper and tpl

dm314:05:03

looks like fun

alandipert14:05:17

JSX before it was cool

onetom15:05:24

🙂 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.

levitanong15:05:53

@alandipert: Do you have any numbers on html syntax usage for hoplon?

jamieorc16:05:04

@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.

micha16:05:44

@jamieorc: we have a separate application in hoplon

micha16:05:02

the hoplon application uses our existing API on the backend

micha16:05:25

we have a castra server that proxies requests to our management API for writes

micha16:05:47

that is to say writes as in creating new entities, modifying entities things like that

micha16:05:08

we read directly from the database for our castra state model

micha16:05:18

this allows us to cleanly separate concerns

micha16:05:31

the castra app never writes directly to the database

micha16:05:41

because that is constrained by the C# ORM

micha16:05:15

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

micha16:05:20

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

alandipert16:05:53

@levitanong: not really - guessing 0? if anyone's using it they're so happy we've never heard a bug report from them

levitanong17:05:25

LISP MASTER RACE 😛

jamieorc17:05:23

@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.

micha17:05:38

@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

micha17:05:22

another helpful thing about hoplon apps is you can have two separate approaches running simultaneously

micha17:05:25

to see how it goes

micha17:05:30

and merge later

jamieorc17:05:01

@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.

alandipert17:05:49

@jamieorc: i think you can :exclude jQuery from hoplon by doing :exclusions [cljsjs/jQuery] in your build.boot, for the hoplon dep

alandipert17:05:21

re: modular builds, all the boot-cljs stuff applies

alandipert17:05:35

i'm not up to date on it but i believe modules are supported these days

jamieorc18:05:59

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.

raywillig18:05:31

@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

alandipert19:05:53

@raywillig: cool. also, being html compatible means being compatible with other markups that compile to html

alandipert19:05:02

like whatever the du jour minimal-syntax markup is

jamieorc19:05:55

@alandipert: Not finding where to place :exclusions [cljsjs/jQuery]. Where does that go? My attempts are either ignored or throw ns errors

alandipert19:05:27

@jamieorc: sorry, that's a lein/boot thing

alandipert19:05:53

e.g. (set-env! :dependencies '[[hoplon "6.0.0-alpha14" :exclusions [cljsjs/jquery]]])

jamieorc19:05:22

Ok, tried that but still got jquery in the build

alandipert20:05:18

so there is an explicit dependency

alandipert20:05:01

seems like maybe boot-hoplon should take an option, whether or not to add that require to emitted ns-decls?

alandipert20:05:09

vs. depending on it in hoplon.core

micha20:05:12

hoplon does require jquery at this time

micha20:05:21

so it should be part of the js file

alandipert20:05:24

yeah the case is when you have your own jquery you want it to use

alandipert20:05:30

in the embedded scenario

micha20:05:46

the answer there is to grep jquery out of the generated js file i would say

micha20:05:57

and do your special thing in a boot task

micha20:05:18

that's like rolling your own special dependency mechanism in clojure

alandipert20:05:18

how about an option on boot-hoplon? whether to build jq in or not?

micha20:05:16

i would be hesitant to do that

micha20:05:29

like we could add options for all kinds of permutations

micha20:05:24

maybe if we implement some kind of :provided scope or something

micha20:05:30

for cljs dependencies

micha20:05:45

that would probably be the way, like in boot-cljs

micha20:05:59

we'd need to modify the cljs compiler probably

micha20:05:04

to support that

micha20:05:15

or monkey patch it

alandipert20:05:49

i guess there are really 2 reasons to do it

alandipert20:05:59

to save download time, and to deconflict w/ another jq

micha20:05:12

deconflicting can be done via maven

alandipert20:05:22

what about jq's deconflict stuff

micha20:05:26

just make an explicit jquery dep

micha20:05:37

running multiple versions at the same time?

alandipert20:05:51

the scenario is you are embedding a hoplon app in a page that already has e.g. jq 1.x

alandipert20:05:01

and you want your hoplon hole to run its own jq 1.y

micha20:05:10

just depend on that version in your project

alandipert20:05:24

but maybe the version that's there isn't compatible with hoplon

alandipert20:05:43

i'm thinking use the jq no conflict stuff so that we can guarantee our jq will work wherever you run

micha20:05:02

that's a good idea yeah

micha20:05:35

then you'd need to use hoplon.core/$ if you want to use jquery inside your hoplon app

alandipert20:05:49

which i think is totally cool

micha20:05:50

you can't safely use js/jQuery

alandipert20:05:55

hoplon/jquery even

micha20:05:33

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

micha20:05:37

to do it sanely

micha20:05:59

like it would need to be engineered correctly i think

alandipert20:05:00

yeah that mitigation seems more on the avoiding double download side of things

alandipert20:05:07

which isn't as high a priority for most people imo

micha20:05:18

because if you don't have a solid dependency mechanism everything falls down

alandipert20:05:28

anyway, any website that's making money is running at least 2 versions of jq 😉

micha20:05:30

so special cases there are not going to improve things

jamieorc20:05:40

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.

alandipert20:05:14

colocating N apps in the same runtime, basically

alandipert20:05:18

it's gonna get interesting

micha20:05:44

the jquery noconflict thing is a great idea

micha20:05:39

i wonder how it interacts with jquery plugins you may have

micha20:05:02

that may be a problem

alandipert20:05:09

true - i guess we don't have a way to force plugins to take our jq version

micha20:05:56

makes the :provided thing seem more attractive maybe

micha20:05:16

like if you have multiple jquerys you'd manage the whole juqery mess outside your hoplon world

micha20:05:26

and have a :provided dependency on jquery etc