React 0.11 is out

[robinheghan]

The big change, or the change that will be most noticable by us reagent users, is the fact that React now renders null to <noscript/>. This should be pretty sweet, as it allows us the use of when and when-not without removing nil from the resulting vector.

[luposlip]

+1 for upgrading reagent to using newest version of react.

Sorry for asking - but has reagent died silently? No major updates since March - that's 4 months ago.

[mike-thompson-day8]

I was worried too. I asked here: https://twitter.com/holmsand/status/496273532368977922

[Whoops]

Glad to hear it's not dead, I'm liking working with Reagent more than Om. For now if anyone needs the 0.11 goodness, for now I have a version on Clojars that uses React 0.11. It passes all tests and works for my app, so I think it's good.

https://clojars.org/whoops/reagent

[ilazarte]

Thanks whoops! I'll be using your fork until Dan can merge :)

[yayitswei]

@Whoops, I tried out your build on Clojars and got an error:

Uncaught Error: Undefined nameToPath for reagent.impl.reactimport

Using Clojure 1.6.0 and ClojureScript 0.0-2280. Any idea what's causing this?

[Whoops]

@yayitswei are you perhaps attempting to require reagent.impl.reactimport? A bit of digging through the history, and it looks like it was removed in this commit: https://github.com/holmsand/reagent/commit/56e11f99c757e3183b8b4d4ac62396435fd18ae7. I can't find any references to it in the current version of the repo, so my best guess at the moment is that you have a reference to it in your codebase somewhere. You might also make sure you are doing a clean build by running lein cljsbuild clean. It's possible cljsbuild is trying to reuse some temporary files that are no longer valid with the new version.

[yayitswei]

@Whoops Cleaning the build worked for me. Thanks for the quick response!

[yogthos]

@Whoops you can also just not use the preamble and include the latest React as a separate Js file or from the CDN and everything works fine.

[ilazarte]

I recommend webjars (http://www.webjars.org/) for pulling in react via maximum lein friendliness :)

[peeb]

@ilazarte webjars is pretty good, agreed, but David Nolen's [com.facebook/react "0.11.1"] artifact also contains an externs file for advanced mode compilation and is also very lein-friendly.

[yogthos]

@Whoops might as well submit a pr with the updates :)

[Whoops]

Actually all I did was update to react 11.1 and merge in the existing pull requests. It looks like since me doing that, someones opened a pull request with react 11 too, so everything in my repo is available through the already existing requests. If/when I do any more work on it though I'll definitely open one.

[yogthos]

Ah good to know, I'm really hoping Reagent gets more momentum as it's absolutely fantastic. :)

[cvillecsteele]

+1 I whole-heartedly agree. Reagent is so simple, elegant, and idiomatic. Love it.

[yayitswei]

+1 from me too.

[luposlip]

+1 from me as well. Den 28/08/2014 21.51 skrev "Wei Hsu" notifications@github.com:

+1 for me too.

— Reply to this email directly or view it on GitHub https://github.com/holmsand/reagent/issues/42#issuecomment-53786181.

[Whoops]

We can always try to keep it going :-). What do people want to see change/improve? I dug through the issues, and it doesn't look like any of them represent outstanding bugs.

[yogthos]

I think the code is in a good state currently, I've used Reagent for a few projects projects of varying size and haven't run into any issues.

Since the API is so simple there really isn't all that much to add to it that comes to mind. One thing might be to have a nicer way to handle post-processing of mounted components. For example, I find myself doing stuff like this fairly often when working with third party Js libs:

(defn mounted-component [component handler]
     (with-meta
       (fn [] component)
       {:component-did-mount
        (fn [this]
          (let [node (reagent.core/dom-node this)]
            (handler node)))}))

Overall, there seems to be a perception problem. I've had a number of people comment on the fact that the GitHub repo hasn't been updated in 5 month and they thought it was abandoned. This thread on reddit is a typical reaction I see when pitching it.

Hopefully Dan gets around to merging the patches and moving to React 11 soon, and I would definitely love to help keep this project going. :)

[cvillecsteele]

@yogthos +1. Yes. I have done this very thing myself with 3rd party libs. And while it's no trouble, a little bit of sugar might be nice.

[peeb]

I had considered forking to remove some of the Makefile ceremony where bower installs React and then copies the js files to the vendor directory and explicitly includes that in :resources-path. It seems a bit redundant when you can just have a lein dependency on [com.facebook/react 0.11.1] which installs into the default :resources-path anyway.

I think also, and this can very possibly be way out of scope of this discussion, there is some redundancy in the debug namespace which could just be replaced with (enable-console-print!).

Like you guys, I guess I am wondering how to proceed best: Fork the repo or keep flagging issues on GitHub?

+1 for @yogthos and @cvillecsteele - I also think reagent is absolutely terrific. Simple and elegant and very approachable.

[mike-thompson-day8]

We're close to releasing (a week?) a set of components built on top of reagent.

Think widgets like Choosen, Tabs, popups, modal dialogs, vbox, hbox, layout splitters, etc. BUT we have heavily relied on flexbox which means it is limited to Chrome, Firefox and IE 11 (and not IE8 or 9 or 10). So it will be a solution for the enterprise space (where you can dictate browser) and not so much retail web.

Anyway, we're all-in on reagent at this point. I would certainly prefer for there to be no forking but ... the time will come.

[yogthos]

I definitely agree that it would be best not to fork the project. Hopefully @holmsand could give us some direction on how he'd like to move forward.

[robinheghan]

@peeb I'm the one who've submitted the 0.11.1 PR. I'd be happy to update it to use the [com.facebook/react "0.11.1"] dependency instead.

I think holmsand replied to someone on twitter that he hopes to continue the project soon. I guess that if he doesn't respond within a reasonable timefrime, we should ask him to transfer ownership of this project to someone else, instead of forking.

[holmsand]

Thanks everyone for all the patience and kind words! And sorry for my lack of involvement lately!

I have kept hoping to get more time to spend on some improvements for Reagent, but it's been darn hard to get there...

Of course I wouldn't mind at all if someone would make a fork. Especially if it is one that could be easily merged back to this project.

And it would of course make me more than happy if more were familiar with the codebase.

But I do plan to finally merge in a new React, and push out a new version within the next couple of weeks (touching wood).

In the meantime: there is nothing magical about the bundled version of React – it is just there for convenience, really. As long as nothing major has changed in React itself, you should be able to include another React, and just skip the :preamble ["reagent/react.js"] part of the project file.

[Whoops]

Yeah I thought hard about removing the Makefile and bower dependency when I did my fork, but since I wasn't aiming for an official fork, I didn't want to screw around with @holmsand's preferred setup.

@yogthos @cvillecsteele , re: the ceremony, it's barely documented, but are you aware of create-class (https://github.com/holmsand/reagent/blob/master/src/reagent/core.cljs#L48)? You'd still have to provide and handler and use dom-node, but it'd be a bit less verbose.

[Whoops]

@holmsand as I recall, I ran into some problems using 0.4.2 with React 11, but everything worked fine when using head (which is at 10), with 11, which is what prompted me to set up a fork. Of course this was about a month ago, so it's all fuzzy :-p.

[yogthos]

@Whoops ah thanks for the tip, I guess updating the docs would be another quick win. I just made a pr for using codox to generate the API docs.

[yogthos]

Hi guys,

I don't know if it's quite the right forum for this, but I started working on a data binding project around Reagent called reagent-forms. If anybody would like to comment on it or help out that would be appreciated. :)

Right now, it provides bindings for some common components, but one of the things I'd like to do is to create a bunch of helpers to get rid of boilerplate around creating Bootstrap components. I'd like to have something similar to om-bootstrap for Reagent.

[seancorfield]

After seeing several people praise Reagent over Om recently, I spent yesterday rebuilding an internal Om/Sablono + Sente app using Reagent + Sente and I have to say that I love the simplicity of Reagent! Awesome work @holmsand - and also @Whoops since I'm using your fork now.

One thing I do miss from Om is cursors to allow a component to focus in on just a subtree of the global state (specifically I have a component with local state that I'd like to switch to global state instead and having a way to construct a cursor to a specific part of the global state would allow for a one line change in the code). Having dug through the Reagent source code, I think this could be implemented as a companion deftype to RAtom so I plan to try it out in my own code first, but once I have it working, I'd like to offer it up to the project.

Given the current state of Reagent, should I just go ahead and send a PR to @holmsand original and hope it gets merged at some point, or would it be more expedient to send a PR to @Whoops fork instead?

[Whoops]

@seancorfield Sounds interesting to me. Yeah the more I think about it, it does sound feasible.

The pull request should definitely go here, I have no intention of my fork becoming permanent.

[seancorfield]

Thanks @Whoops - I'll probably tackle it some time this week. Sounds like you've been merged PRs from this repo into yours anyway?

[Whoops]

Yeah mine is basically just this one, but with the open PRs merged in.

[seancorfield]

@Whoops (and others) I just submitted PR #46 to add cursor support, with tests. An open question was what -pr-writer should do (there's a big comment in there asking for guidance). Since no tests check the printed output, I deferred the decision.

I also have this working (and further tested) in our own app at World Singles.

[kylecordes]

I see that React is now at 0.11.2 - how about an update all the way there?

Rather than pound on @holmsand, maybe someone else could make a "friendly fork" which attempts update, tweak, bring in some PRs, and generally make it super-easy for @holmsand to confirm and update the official code with less time spent?

[seancorfield]

@kylecordes That would be https://github.com/Whoops/reagent fork - which is at 0.4.3 with most of the PRs merged in and React 0.11 (or 0.11.1?). It's what we're using at World Singles, until @holmsand gets time to bring this original repo up to date.

[peeb]

@kylecordes you're also completely free to use [com.facebook/react "0.11.2"] in your project.clj - it works just fine. That's what I'm doing, for the record.

Reagent doesn't depend on any hard-coded version of React, it's just there as a courtesy.

[Whoops]

My fork bundles 11.1, but I strongly recommend using the [com.facebook/react "0.11.2"] approach. I think having it as a separate dependency is much cleaner than the bundled approach.

[kylecordes]

@seancorfield and @Whoops thank you, that is very helpful. For anyone else reading this, the current dependency to list is [whoops/reagent "0.4.4-alpha"]

[yogthos]

@holmsand, since it appears that you're quite busy and @Whoops has been keeping his fork up to date, would you consider adding him as a collaborator on the main project. It seems like that would be a better approach than keeping a fork as it will likely diverge at some point.

[kylecordes]

By the way, I found that [org.webjars/react "0.11.2"] works more easily for me than [com.facebook/react "0.11.2"], as it is set up such that clj-webjars can serve it in development.

[Whoops]

With https://github.com/holmsand/reagent/pull/46, they have diverged, which is a major part of why I waited so long to merge it, and then marked that release as alpha, since I can't guarantee them making it into the main project.

While I'm willing to do it if that's what people want, I'm not sure I'm the best choice: I've been doing Clojure a little while but am a complete newbie to Clojurescript. Really all I've done is merge in some pull requests and update a dependency. I think @yogthos or @seancorfield is a more natural choice, or perhaps it's time to open this up as a community project and add a few contributors

[yogthos]

I can definitely help out with basic maintenance and testing/merging new features. Creating an org around the project might be the ideal solution though. Then it can also be an umbrella for any related projects all in one place.

[seancorfield]

:+1: for the org. Then reagent-forms could move to it as well? And maybe someone would be inspired to create a reagent-bootstrap (if there isn't one already?).

[yogthos]

@seancorfield I would definitely love to move reagent-forms to the org. :) I considered doing something like reagent-bootstrap before, but since reagent already uses hiccup syntax, I'm not sure if there would be a huge benefit. You could probably abstract some of the more common controls, but then you'd also have to make sure that's kept up to date as bootstrap evolves.

[mike-thompson-day8]

I'm in favour of asking Dan to appoint additional maintainers.

The proof of the pudding is always in the eating and Dan looks to be too busy to meaningfully take this forward at the moment (unless he expects a quite different circumstance very soon). We're now two version of React behind on the main repo, and that gives off a bad smell. I'd like to see a thriving community around this nice library.

I also feel that each library (forms, cursors, etc) should be left separate and not folded into the core of reagent. Including them in the core would seem premature at this point. We aren't far enough along to know what approach is right. Let's list interesting, higher level libs in the README instead.

Recent developments like derive (or a version adapted to reagent) might provide a better/more general solution than the current cursor's approach proposed by Sean (thanks!). Who knows?

My company will soon open source a set of reagent components, kinda based on bootstrap and kinda based on flexbox, etc. (I've been threatening to do this for a while, but the end of next week looks like a sensible target now). So I, for example, wouldn't want to see a forms library folded in to the core of reagent.

[yogthos]

@mike-thompson-day8 I definitely think that keeping things modular is a good way forward. The org idea seems to make the most sense for that. This is how Ring development works as well. There's the Ring org, and libs are incubated there before being merged into ring-core proper.

[Whoops]

I don't think anyone was talking actually merging reagent-forms into reagent itself, but rather have it be a separate project under the org. Cursors I'm less sure about if that should be kept separate or not. It's a pretty nice abstraction with a small implementation that goes a long way toward improving working with nested state. Plus the advantage of the closure compiler means that if you don't use it, it won't actually get compiled in to the final result. That said, it could be implemented as a library pretty easily, and referenced in the docs on the main project. Plus I've actually pondered if RAtom itself should be split out, there have been a few times that I've wanted and atom that I could easily track when it was derefed.

[seancorfield]

Just to be clear, I was suggesting moving Reagent-related projects under a common Reagent organization to create a central ecosystem. I was not suggesting merging things into reagent.core (although I think cursor fits - but it could easily be a separate library under a Reagent organization if folks preferred).

[mkhoeini]

+1 for the org. Reagent is magnificent, and it would be too much of a waist if people stopped using it because it doesn't receive the attention it deserves. ;) Creating an org and allowing multiple people and projects in would certainly help Reagent going more fluidly forward.

[borkdude]

+1 for the org also. I'm also for modularizing different implementations of cursors.