You made the analogy to games/graphics, React model treats the DOM akin to a graphics buffer, and they themselves present it as similar to the doom3 architecture. In practice, it feels a lot like a scene graph, with the update/render methods on every component.
I don't know how easy it is to fit javafx into this, but it works out with the DOM pretty well. If JavaFX can be described as a renderer of a static data structure, then you should be able to do the same kind of tree-diffing optimizations that React does to minimize what needs to be redrawn, and to present a functional/data interface. On Tue Jan 13 2015 at 11:52:36 AM Colin Yates <colin.ya...@gmail.com> wrote: > One lesson I would share is that things are usually much quicker than > we expect. Always prove it is too slow before believing your > intuition. > > On 13 January 2015 at 16:28, MS <5lvqbw...@sneakemail.com> wrote: > > If I come up with anything that might usefully tie Clojure data > structures > > to JavaFX UI elements in a clean way, I may release it on github. For > now > > it's just one or two .clj files with all my random monkey-coding, using > lots > > of half-examples from various sources, which is pretty much how I > learn. I > > played around with Seesaw (Swing-based) for a little bit, but it started > to > > get a little too abstract for me, and anyway, as a friend of mine > recently > > said, Swing looks like ass, even if you set it to look like the native > > platform, and I need my app to be "rich", etc. There's also a certain > part > > of me that feels that "all these" asynchronous libraries out there > (react? > > core.async? I really don't know what I'm talking about [I'm a hardware > > engineer]), add a lot of overhead with threads, etc., and I may be wrong, > > but it feels like there would need to be fewer layers between clicking > the > > mouse and having something show up. I believe any cad/drawing/design > tool > > needs to be as reactive and real-time as any game, so max 16ms latency. > I'm > > not saying I have any evidence these libraries are slow... I'm just > saying > > it feels like overkill when I'm not writing a big web server or anything. > > I'm probably wrong. > > > > On Tuesday, January 13, 2015 at 8:05:40 AM UTC-8, tbc++ wrote: > >> > >> I've long thought that the Clojure world needs a JavaFX/React hybrid. > >> JavaFX2's API is extremely consistent, making it quite easy to program > >> against, but yes it still requires bindings and in-place mutation. > >> > >> However a React-like diff-ing engine on it would be quite impressive. > But > >> now you're into the fun land of writing a library in order to write your > >> app. > >> > >> On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates <colin...@gmail.com> > wrote: > >>> > >>> Wow, there is a lot to deal with :), so let me throw out some ideas: > >>> - have you considered building a web-app instead of a desktop app? If > >>> so, have a look at one of the react based languages (om or reagent > would be > >>> my choice). Alternatively take a look at other > >>> http://en.wikipedia.org/wiki/Functional_reactive_programming > libraries. > >>> > >>> It is a different way of working, but its programming model restricts > you > >>> in a way that removes many problems (if you see what I mean). > >>> > >>> Also, I would be reaching for an in-memory database (assuming a server > >>> isn't involved) about now, datatomic would be the obvious choice. > >>> > >>> I don't think what you are trying to do is stupid, I do think you might > >>> want to do some thought experiments about different architectures and > >>> paradigms (specifically FRP related paradigms). > >>> > >>> Oh, and have a quick scan through http://swannodette.github.io/, there > >>> are a few "mind-changing" posts. > >>> > >>> On Monday, 12 January 2015 18:53:07 UTC, MS wrote: > >>>> > >>>> (Cross-posted on StackOverflow) > >>>> > >>>> I'm trying to design a desktop UI for schematics, layout, drawing > stuff. > >>>> Just looking for high level advice from actual software designers. > >>>> > >>>> Assuming an in-memory "database", (clojure map of arbitrary depth for > >>>> all user data, and possibly another one for application preferences, > etc.), > >>>> I'm examining how to do the model-view-controller thing on these, > where the > >>>> data may be rendered *and modified by* any one or more of: > >>>> > >>>> 1. A standalone text field that shows a single parameter, such as box > >>>> width. > >>>> 2. An "inspector" type of view that shows multiple parameters of a > >>>> selected object, such as box width, height, color, checkboxes, etc. > >>>> 3. A table/spreadsheet type of view that shows multiple parameters of > >>>> multiple objects, potentially the whole database > >>>> 4. A graphical rendering of the whole thing, such as both schematic > and > >>>> layout view. > >>>> > >>>> Modifying any one of these should show up immediately in every other > >>>> active view, both text and graphical, not after clicking "ok"... so > no modal > >>>> boxes allowed. If for some reason the table view, an inspector view, > and a > >>>> graphical rendering are all in view, dragging the corner of the box > >>>> graphically should immediately show up in the text, etc. > >>>> > >>>> The platform in question is JavaFX, but I'd like a clean separation > >>>> between UI and everything else, so I want to avoid `bind`ing in the > JFX > >>>> sense, as that ties my design data very tightly to JFX Properties, > increases > >>>> the graininess of the model, and forces me to work outside the > standard > >>>> clojure functions for dealing with data, and/or deal heavily with the > whole > >>>> `getValue`/`setValue` world. > >>>> > >>>> I'm still assuming at least *some* statefulness/mutability, and the > use > >>>> of built-in Clojure functionality such as the ability to `add-watch` > on an > >>>> atom/var/ref and let the runtime signal dependent functions. > >>>> > >>>> Platform-specific interaction will rest tightly with the actual UI, > such > >>>> as reifying `ActionListener`s, and dealing with `ObservableValue`s > etc., and > >>>> will attempt to minimize the reliance on things like JavaFX > `Property` for > >>>> actual application data. I'm not entertaining FRP for this. > >>>> > >>>> I don't mind too much extending JFX interfaces or making up my own > >>>> protocols to use application-specific `defrecord`s, but I'd prefer > for the > >>>> application data to remain as straight Clojure data, unsullied by the > >>>> platform. > >>>> > >>>> The question is how to set this all up, with closest adherence to the > >>>> immutable model and minimal (or well-bounded) dependence on JFX. I > see a > >>>> few options: > >>>> > >>>> 1. Fine-grain: Each parameter value/primitive (ie Long, Double, > >>>> Boolean, or String) is an atom, and each view which can modify the > value > >>>> "reaches in" as far as it needs to in the database to change the > value. > >>>> This could suck as there could potentially be thousands of individual > values > >>>> (for example points on a hand-drawn curve), and will require lots of > >>>> `(deref...)` junk. I believe this is how JFX would want to do this, > with > >>>> giant arrays of Properties at the leaf nodes, etc., which feels > bloated. > >>>> With this approach it doesn't seem much better than just coding it up > in > >>>> Java/C++. > >>>> 2. Medium-grain: Each object/record in the database is an atom of a > >>>> Clojure map. The entire map is replaced when any one of its values > changes. > >>>> Fewer total atoms to deal with, and allows for example long arrays of > >>>> straight-up numbers for various things. But this gets complicated > when some > >>>> objects in the database require more nesting than others. > >>>> 3. Coarse-grain: There is just one atom: the database. Any time > >>>> anything changes, the entire database is replaced, and every view > needs to > >>>> re-render its particular portion. This feels a bit like using a > hammer to > >>>> swat a fly, and a naive implementation would require everything to > re-render > >>>> all the time. But I still think this is the best trade off, as any > >>>> primitive has a clear access path from the root node, whether it is > accessed > >>>> on a per-primitive level or per-record level. > >>>> > >>>> I also need the ability for one data template to be instantiated many > >>>> times. So for example if the user changes a symbol or shape which is > used > >>>> in multiple places, a single edit will apply everywhere. I believe > this > >>>> also requires some type of "pointer"-like behavior. I think I can > store a > >>>> atom to the model, then instantiate as needed, and it can work in any > of the > >>>> above grain models. > >>>> > >>>> Any other approaches? Is trying to do a GUI editor-like tool in a > >>>> functional language just stupid? > >>>> Thanks > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "Clojure" group. > >>> To post to this group, send email to clo...@googlegroups.com > >>> Note that posts from new members are moderated - please be patient with > >>> your first post. > >>> To unsubscribe from this group, send email to > >>> clojure+u...@googlegroups.com > >>> For more options, visit this group at > >>> http://groups.google.com/group/clojure?hl=en > >>> --- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Clojure" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an > >>> email to clojure+u...@googlegroups.com. > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> > >> > >> > >> -- > >> “One of the main causes of the fall of the Roman Empire was that–lacking > >> zero–they had no way to indicate successful termination of their C > >> programs.” > >> (Robert Firth) > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to a topic in the > > Google Groups "Clojure" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/clojure/Ut-HkNTqRUo/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
