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?

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

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

@nberger: thanks chief

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

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

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

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

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?

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.

@ulsa: what about using json web tokens? http://funcool.github.io/buddy-auth/latest/#jws-token-stateless

https://stormpath.com/blog/token-auth-spa/

easily applied to cljs

@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

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

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

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

exactly

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

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

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

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

Yea, I think so

is there any particular disadvantage with SPA that stands out?

I'll read up on it

routing

Search robots cannot parse the generated content

and you get a worse ranking

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

and some more I cannot think of right now

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

thx

np

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

so many choices...

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

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

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

yes, wise words indeed

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

plexus: "search engines"? or google?

google at least I admit not being sure about the others

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

like cross site request forgery

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

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

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

https://www.youtube.com/watch?v=exwxOwT07pk

he explains it better

@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

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

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

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

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

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

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

the session cookie is already also a token

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

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

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

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

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

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

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

obviously it has more details for different situations...

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

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

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

and yes.. you can steal that token

like any sesion cookie token

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

the security is almost identical in both situations

but that's assuming SSL can't be hacked

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

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)

true

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 ?

https://github.com/matthiasn/BirdWatch

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

@benzen ^^

oh very nice, thanks

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

@niwinz: thanks for the explanation

sveri: 😉

@bensu: great, thanks!

@upgradingdave: electron is very suited

@upgradingdave: I hope to publish a small guide soon

@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

so looking forward to looking into electron

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

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

But that maybe because of their dependencies

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

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

@martinklepsch: ^^

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)

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

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

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.

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

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

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

yeah, the material design implementations out there, like materialize

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

but maybe my concern is unfounded.

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

http://materializecss.com/

http://www.getmdl.io/

@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

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

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

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

took me a while to figure that out.

@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

yeah

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

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

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

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

the floating labels are done via js

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

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

all that magic is in there

i’m yet to try it out with materializecss

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

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?

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

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

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?

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

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

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

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

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

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

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

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

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

ahh

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

@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

that gets rid of the warning, thanks @erik_price

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

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

@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

cool, thanks jackjames .

Is Hickory abandonware? https://github.com/davidsantiago/hickory

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

@mfikes: planck looks cool

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

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

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

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

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

@pesterhazy: See https://gist.github.com/mfikes/c7da1e7dfded26c7ceb9

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

Sure.

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

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

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

@jeluard: Disregard my earlier comment. User error.

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

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

@zane it depends on the :type of your hickory structure, see https://github.com/davidsantiago/hickory/blob/master/test/hickory/test/render.cljx#L12

ClojureScript 1.7.48 works OK with Clojure 1.8 alpha