Hello Alex - Thank you for your response to my question here:
http://www.impredicative.com/pipermail/ur/2015-July/002049.html I see from your website that you do consulting. If you are doing projects for clients using Ur/Web, then that must be very exciting. Research so far: I have been studying the example based on Mithril + RxJS http://www.ericponto.com/blog/2015/05/31/rxjs-and-mithril/ I imagine it might be quite similar to what one might code natively in Ur/Web FRP). For example, see this code fragment (using Mithril + RxJS): controller() { this.model = m.prop({}); Rx.Observable.fromEvent(el, "keyup") .map(pluck("target")) .filter(el => el.matches("input")) .map(pluck("value")) .filter(val => val.length > 2) .debounce(250) .distinctUntilChanged() .flatMapLatest(searchGithub) .subscribe(this.model); } It looks very functional! So it might be straightforward to rewrite this in Ur/Web. (Although I would have no idea "where" to situate it within an overall _.ur module. Currently it is a call to a function, inside some JavaScript function called Controller(). I have no idea how this could correspond to code in Ur/Web.) Using FFI? I also had investigated two other possible approaches, involving using Ur/Web FFI to "wrap" an already existing full-fledged JavaScript library for autocomplete widgets, such as Select2 and twitter typeahead.js. I thought using FFI might also be a good strategy, since such existing libraries would probably be heavily optimized already, to work well with the browser and with the remote database. My initial attempts using these two approaches gave compile errors: https://github.com/StefanScott/urweb-crudcrud/issues/1 https://github.com/StefanScott/urweb-crudcrud/issues/2 Native FRP, versus foreign (FFI) Do you really think it would be better to program an autocomplete widget natively using Ur/Web's FRP, rather than "wrapping" some existing, full-featured, heavily-optimized JavaScript library which already provides a nice autocomplete widget? I understand there would be trade-offs using either approach (native or foreign). On the one hand, a native solution in Ur/Web would probably be simpler and more elegant - but I do not know how optimized Ur/Web's generated client-side code might be. I imagine that it would work fine though - and the code could probably be fairly short. On the other hand, it would seem to be unfortunate if Ur/Web should disregard all the fine JavaScript libraries already in existence. For example, much of Clojure's success is due to the fact that it runs on the JVM - so all Java libraries are automatically available in Clojure - providing the benefits of many person-years of labor. Whenever I post questions on the Mailing List, Adam usually says "it is better to just program this in Ur/Web - ignore the existing solutions in JavaScript". But are all existing JavaScript libraries so bad, that we should simply re-write them all from scratch in Ur/Web? This doesn't seem realistic - particular in view of the small size of the community. I was hoping to simply use FFI and get the benefits of some existing full-fledged, heavily optimized JavaScript libraries for autocomplete widgets. But given the compiler errors shown in the two GitHub Issues links above, I have not been able to understand how to pursue the FFI approach. Elsewhere in this thread, Sergey has provided some pointers to code he wrote for using JavaScript libraries - as well as some functions Unsafe.s2xhead and Unsafe.s2xbody, which may help avoid some of the compile errors I was getting. I'm not much of a front-end or JavaScript programmer! I should confess that I have never felt very comfortable reading JavaScript - and I have never written anything important using it. It has has always been hard for me to understand the syntax and semantics of JavaScript (but easier to read things like CoffeeScript, Babel, ClojureScript, which use a more "functional" syntax). My experience is more in algebraic data types (I have used the Maude language a bit, and studied ML and Haskell a lot) and back-end (SQL) data modeling. So, I am not confident of my ability to write good code involving events, timing, throttling / debouncing, interactivity - all the stuff involved in front-end development. I perceive that these problems involve "co-algebraic process types" - the dual of my experience in algebraic data types. But now I think perhaps must force myself to learn enough front-end programming just to get the few data-bound UI widgets I need to put on the front-end of all databases: - autocomplete widget - datagrid - master-detail form layout (a "parent" datagrid linked to a "child" datagrid, via an SQL foreign key) Again, thank you for your encouragement. I am surprised that Ur/Web (which is specialized to work with databases) still lacks some kind of data-bound menu-widget to let the user select the value for a foreign-key. And given my lack of experience with front-end programming and JavaScript, I am probably the worst person to attempt to program this sort of thing. However, I am highly motivated to see this kind of autocomplete widget available, so I will continue to look for ways to do so. - Stefan Scott
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
