[Ur] Live demo and tutorial for a simple autocomplete widget written using RxJS + Mithril + 6to5/Babel + HTML5 <datalist>. Could this provide a basis for a simple "native" autocomplete widget in Ur/Web?

[Stefan Scott Alexander]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150713/8beaa8ae/attachment.html>