Fork me on GitHub
#clojurescript
<
2015-08-14
>
zane00:08:56

If I'm loading an Om component into a page that already has other JavaScript that's using React, is there a way to get Om / CLJS to use that instance of React rather than bringing its own?

zane00:08:10

I'm grappling with bugs that I think are due to the two instances of React clashing.

nberger00:08:51

@pandeiro: what a good repro repo you have there! No idea about the issue, will take a look

pandeiro01:08:54

@tel: i think cljs.test is probably the standard thing to build around now, it's part of the cljs distribution

tel01:08:17

@zane you can exclude react [org.omcljs/om "0.9.0" :exclusions [cljsjs/react]]

bensu09:08:05

@tel: @zander right! use :exclusions in all projects that pull react in, and then require it yourself.

bensu09:08:51

@pandeiro: @tel last I checked with @cemerick he was planning on slowly migrating to cljs.test

ulsa10:08:55

I'm struggling a little to get my head around how to do auth in an SPA. There's the Hoplon/Castra approach, where all backend calls can be checked for auth with :rpc/pre. There's [Yuggoth](https://github.com/yogthos/yuggoth), where Basic Auth is used to login, and session is checked in the SPA. It uses a single Selmer template and Secretary for #-based links. Then there's [Closp](https://github.com/sveri/closp), which uses multiple Selmer templates and Buddy's wrap-access-rules to do URI-based auth. Is my summary correct? Can somebody perhaps point out pros and cons with these approaches? Any recommendations or other examples to look at?

ulsa10:08:48

My main concern is whether it's somehow "better" to use multiple pages and URI-based auth, than a single-page template and #-based routes.

greywolve10:08:10

easily applied to cljs

sveri10:08:53

@ulsa: If you have a "pure" cljs application I'd also take another look at JWS tokens. OTOH closp comes as it comes because in my experience you hardly ever have a pure cljs application but there are always some kind of forms or things done easier if they come prerendered from the server

ulsa10:08:23

I do have similar reqs that closp handles, like anonymous, users and admins, but I'm suspecting that can be handled client-side as well

ulsa10:08:42

password change, signup, TOS, etc, but is it somehow easier to do with server-side rendering?

sveri10:08:58

@ulsa: of course, you can handle everything on the client side. the question is, what do yo gain by doing it on client side?

sveri10:08:26

There is a whole debate going on about SPAs I'd advice you to read about the disadvantages especially and then think about it again

ulsa10:08:24

OK, and what does token-based bring to the table?

sveri10:08:29

From what I read jws tokens are stateless, but I never used them anywhere up to now so maybe someone else knows more

ulsa10:08:53

so getting away from the server-based session then, I guess

sveri10:08:07

Yea, I think so

ulsa10:08:32

is there any particular disadvantage with SPA that stands out?

ulsa10:08:43

I'll read up on it

sveri10:08:02

Search robots cannot parse the generated content

sveri10:08:14

and you get a worse ranking

sveri10:08:39

lot of requests to the server which may be a problem if you're on mobile somewhere with a bad bandwidth

sveri10:08:58

and some more I cannot think of right now

sveri10:08:16

That said, most problems are solvable more or less, but they require you to do extra work and to think ahead

ulsa10:08:11

@greywolve: thx for stormpath, looks interesting, since I do have SPA and REST

ulsa10:08:27

so many choices...

greywolve10:08:07

np simple_smile i haven't used JWS yet but i'm planning on trying it out soon for an app i'm building

ulsa11:08:10

so the three immediate choices I see now are: go with session-based SPA with say Basic Auth, or perhaps token-based, or rework my SPA to a more server-side rendered approach à la Closp

sveri11:08:23

Yep and as Rich said, always be aware of the disadvantages of a technology, know your tools simple_smile

ulsa11:08:36

yes, wise words indeed

plexus11:08:36

search engines can read SPAs just fine nowadays. The main challenge is that you're re-inventing routing/navigation. It takes work to makes links and urls work as people would expect

sveri11:08:04

plexus: "search engines"? or google?

plexus11:08:21

google at least simple_smile I admit not being sure about the others

plexus11:08:23

a benefit of tokens vs (cookie based) sessions is that you sidestep a lot of security issues that come with cookies

plexus11:08:52

like cross site request forgery

plexus11:08:18

this is one of the reasons the Travis CI web app was using tokens early on

ulsa11:08:10

is there something that wrap-anti-forgery doesn't do away with?

plexus11:08:32

depends on what you're doing... there's subtle stuff because of how the same-origin policy works for cookies. Like if you're working on subdomains of the same top-level domain, or using iframes

plexus11:08:10

he explains it better

sveri11:08:00

@plexus: Interesting talk, I just cannot imagine any other technology is much better security wise. I guess one could pick anything and have a talk like this about it simple_smile

plexus12:08:09

@sveri: I'm not so sure about that. cookies stem from an age when security on the web wasn't as important as it is now. Nobody was banking or shopping online yet, or had their whole live "in the cloud"

plexus12:08:19

the current "spec" is just what browsers implemented and copied from each other, eventually settling on some common functionality, and now all of that is set in stone because of backwards compatibility

plexus12:08:25

the point being: you have very little control over cookies once they're set, browsers will send them back on pretty much any request to the same domain, even when originating from XHR, flash, images embedded in other pages, etc. With tokens you have better control

sveri12:08:40

@plexus: I fully agree with what you said. This is all true. Still, there is a but 😄 But, the way I see it is, that it just means tokens are not wieldly used enough to justify the amount of work to crack it for a large audience, so I think it's just a matter of time until this gets exploited too.

niwinz12:08:09

@sveri: the tokens are in use since the http session exists

niwinz12:08:27

the session in cookies, exists for many years also...

niwinz12:08:37

the session cookie is already also a token

niwinz12:08:06

I think that your afirmation that "tokens are not wieldly used enough" is not truly IMHO

niwinz12:08:06

The encryption schemes used for create stateless tokens are already proven secure for many years

niwinz12:08:36

and similar encryption schemes are used for today secure communication...

niwinz12:08:13

so we can treat stateless tokens (jwe concretelly) strongly secure, I think.

greywolve12:08:19

@niwinz: do you need a short expiry to be strong secure?

niwinz12:08:58

no, if you have read a NIST recomendations or similar recomendations

niwinz12:08:36

the time for renew a key for some encrypted data is a year...

niwinz12:08:56

obviously it has more details for different situations...

greywolve12:08:30

but surely you can still just steal that token then and use it?

niwinz12:08:41

furthermore, it much depends on the application needs that the security as is

niwinz12:08:28

if you don't want user to be logged or use the same token for much time, you should implement some policy for renew tokens..

niwinz12:08:08

and yes.. you can steal that token

niwinz12:08:19

like any sesion cookie token

niwinz12:08:04

if you are using not secure transmortes (without ssl), both the tokens and session cookies can be stolen

niwinz12:08:20

the security is almost identical in both situations

greywolve12:08:34

but that's assuming SSL can't be hacked

niwinz12:08:12

obviously... but i'm saying... if you are using cookies you have the same problems... cookies are not safe for man-in-the-middle attacks

niwinz12:08:13

In security and cryptography, in some time/step we should make some assumptions about the security... as great example is RSA where we assume that is secure because no one can solve the factorization problem (i'm not sure about this naming)

benzen12:08:42

Hi, i'm looking for example of usage of stuart-sierra/component (or alike) on clojurescript (and specially with reagent) any advice where to look at ?

greywolve12:08:50

his cljs client uses a component approach, he also has a book out on building that system

benzen13:08:40

oh very nice, thanks

upgradingdave13:08:51

Hi, any suggestions for writing desktop apps with clojurescript? I was going to take a look at electron, any other projects worth looking into?

sveri13:08:56

@niwinz: thanks for the explanation simple_smile

niwinz13:08:40

sveri: 😉

tel13:08:33

@bensu: great, thanks!

martinklepsch13:08:38

@upgradingdave: electron is very suited

martinklepsch13:08:51

@upgradingdave: I hope to publish a small guide soon

upgradingdave13:08:30

@martinklepsch: great, thanks. I write a lot of little clojure(script) programs for things like parsing logs and doing small reports for work. I usually give the customer a command line program to run, but I’m looking to start making it nicer for them by providing gui's

upgradingdave13:08:49

so looking forward to looking into electron

caskolkm13:08:42

@martinklepsch: i’am also interested in your electron guide 😄

dmich14:08:30

Isn't electron pretty big? I saw in Atom/Electron slack team that people where having 200MB exes?

dmich14:08:49

But that maybe because of their dependencies

dmich14:08:21

For example, the slack 1.1.8 Windows App dir (which uses Electron I'm pretty sure) is 150MB.

mfikes14:08:07

@sekao: I am now experiencing what appears to be a compiler bug related to your 0 problem. (If I touch one of my .cljs files and simply rebuild, then the emitted JavaScript has cljs.core.truth_ calls where it didn’t previously—and this causes things to start working for me.) The challenge will be in creating a minimal repro.

dmich14:08:15

Whereas I have a fairly complicated C# + WPF GUI app that is only about 2MB (of course that requires that .NET 4.5 is also installed, but .net apps all can share that)

sekao14:08:20

@mfikes interesting, that explains why I was having trouble reproducing it

mfikes14:08:24

@sekao: A theory is that *unchecked-if* gets set but not restored, and this affects code subsequently compiled in the same compilation run.

jonas15:08:40

I would be interested in adding https://github.com/callemall/material-ui to https://cljsjs.github.io. But before I dive in: Has anyone successfully used material-ui components from e.g. Reagent ? Any experience reports would be very valuable.

jonas15:08:00

I also don’t know how difficult it will be to package it for cljsjs as I haven’t done anything like that before

roberto15:08:06

I’ve used material design with reagent, but not material-ui-components. Not sure what is the benefit you get.

jonas15:08:35

@roberto Do you mean you have used the principles of material design, but no particular css/js library?

roberto15:08:03

yeah, the material design implementations out there, like materialize

roberto15:08:45

it kind of freaks me out to have a “component” that depends on some external css framework. It can get gnarly when moving away from that particular css framework (e.g. moving from bootstrap to material design).

roberto15:08:25

but maybe my concern is unfounded.

jonas15:08:50

@roberto I got the feeling that material-ui don’t use any external stylesheets.. Everything is inline and they have some (weird?) way of customizing it via a top level React component.

jonas16:08:00

@roberto thanks for the links. I agree that material-ui seems to be something that you use more like a framework and would be more difficult to move away from when needed

jonas16:08:50

It’s also difficult to assess how well it will work with Reagent

roberto16:08:07

yeah, I think there is some overhead when dynamically modifying the DOM, which happens alot in SPAs.

roberto16:08:53

you have to call a js function provided by the material design framework, that looks at all elements in the DOM

roberto16:08:11

took me a while to figure that out.

jonas16:08:37

@roberto it’s the same with something like bootstrap, right? The pure css parts work well with React (and the cljs wrappers) but many of the js required parts doesn’t really fit the react model

roberto16:08:49

I found myself having to call this on every :component-did-update or :component-did-render `

roberto16:08:02

(defn component-did-update
  [args]
  (dom/register-mdl-components))

jonas16:08:56

ouch. That doesn’t seem very nice. I guess this was with mdl?

roberto16:08:46

yeah, you need this when you display a form with floating labels

roberto16:08:58

the floating labels are done via js

roberto16:08:24

and, lets say you move from page 1 to page 2, where page 2 will mount a form.

roberto16:08:45

the floating labels won’t show correctly unless you call register-mdl-components

roberto16:08:49

all that magic is in there

roberto16:08:55

i’m yet to try it out with materializecss

jonas16:08:16

@roberto this is really valuable information. Thanks a ton!

erik_price18:08:48

I have a ClojureScript codebase that is using an older version of ClojureScript, built with lein-cljsbuild. It appears that some significant advances were made in the tooling that is built-in to ClojureScript over the past six months or so. Is lein-cljsbuild still the recommended build system, or is there something else?

nullptr18:08:58

lein-cljsbuild is running a bit behind, but it’s still the lowest friction option for real projects with lib dependencies

erik_price18:08:00

In my case, I don’t see how I could not use lein, because of all of the dependencies in my project. Does that automatically mean cljsbuild? (Mind you I have nothing against using cljsbuild; I just wanted to know what contemporary CLJS projects do.)

jeremyraines18:08:55

I am doing some cljs with figwheel, and I have a function that starts off like (defn sorted-items [{:keys [sort items]} state], and I later call it in one place, with just state going in as an arg. But I'm getting this warning, which is messing with the auto-reloading: WARNING: Wrong number of args (1) passed to outfit-sets.core/sorted-items . . . anyone have any idea why that could be happening?

erik_price19:08:12

@jeremyraines: you call a 2-arg function with just 1 arg and get a warning when you compile?

jeremyraines19:08:50

Hmm, is that my mistake? Sorry, just getting started . . . but I thought my arglist for defn was just destructuring the single arg state

jeremyraines19:08:37

the thing is, the program works the way I want it to, so I figured it was something odd with the compilation or my environment

jeremyraines19:08:56

i just have to refresh the page manually everytime b/c of the warning

erik_price19:08:58

I think what you want is (defn sorted-items [{:keys [sort items] :as state}]

jeremyraines19:08:01

i'll try that, thanks. I thought that way was just for when I also want access to the full state arg inside the fn

erik_price19:08:24

It is. Maybe I misunderstood what you’re doing. I thought you were saying sorted-items is a one-arg function.

jeremyraines19:08:09

it is. It takes state, but I'm only interested in the :sort and :items pieces of it

erik_price19:08:23

Oh, then just use (defn sorted-items [{:keys [sort items]}]

maio19:08:45

It seems that my Om components re-mount often. Any idea what might be the problem?

jackjames19:08:22

@erik_price: there was some discussion here a few days back around cljsbuild, new build tooling, and even newer alternatives for leveraging the new tooling: http://clojurians-log.mantike.pro/clojurescript/2015-08-11.html

jeremyraines19:08:06

that gets rid of the warning, thanks @erik_price

jackjames19:08:36

@erik_price: its fluid atm, but now probably a reasonable option to use lein for managing deps without using cljsbuild (i believe that's what mies does now)

jackjames19:08:56

@erik_price: so aorn, cljsbuild generally works, but may simply not be necessary

mfikes20:08:06

@sekao: I filed a minimal repro that I believe is indicative of what both you and I are seeing: http://dev.clojure.org/jira/browse/CLJS-1423

erik_price20:08:10

cool, thanks jackjames .

zane20:08:24

I can't seem to get the rendering to work with recent versions of cljs.

pesterhazy20:08:14

@mfikes: planck looks cool

zane20:08:17

Or is there another HTML transformation library I should be considering?

zane20:08:39

Enfocus appears to only work on the DOM itself, rather than being able to parse and transform strings.

jeluard20:08:53

@zane as far as I know it should work fine. What issue do you have?

pesterhazy20:08:33

@mfikes: just tried it out, and slurp works simple_smile. I was wondering if you have plans for something that works on Linux as well as on OSX?

zane20:08:24

@jeluard: I'm having trouble calling any functions in hickory.render.

jeluard20:08:44

@zane I am not using the rendering part so there might be something specific here. Can you open an issue with relevant details?

pesterhazy20:08:30

@mfikes: very interesting, thanks for the link. Yes, I was thinking about cljs on node.js

pesterhazy20:08:34

I desparately want to see shell scripting in Clojure(Script), in particular a port of scsh

jeluard20:08:45

@zane Are you interested in rendering hiccup to the DOM or just to a string?

zane21:08:03

@jeluard: Disregard my earlier comment. User error.

zane21:08:16

@jeluard: There's no render-to-html-fragment, right?

zane21:08:47

It's always going to wrap with <html><head></head><body>…</body></html>?

stuartsierra21:08:15

ClojureScript 1.7.48 works OK with Clojure 1.8 alpha