Similar ideas to Concur UI lib

[ajnsit]

Hi, you might be interested in checking out my Concur UI library which takes these ideas to their logical extreme!

It was originally written for Haskell (https://github.com/ajnsit/concur), then Purescript (https://github.com/ajnsit/purescript-concur), and even Javascript (https://github.com/ajnsit/concur-js). But the Javascript port is more of a proof of concept. Perhaps we can figure out a way to collaborate on the JS version?

There is some documentation here - https://github.com/ajnsit/concur-documentation/blob/master/README.md

[texastoland]

I didn't realize you ported Concur to JavaScript! Did you notice anything specific the two libraries could learn from each other?

[ajnsit]

Concur-js is more of a proof of concept right now, the API and performance could certainly be better. Crank is probably more pragmatic for JS development and does things in a more JS idiomatic way.

However, Concur's semantic model is very well developed and brings a bit more of a disciplined approach, which I think scales better in the long run. For example, Concur components have return values and can be combined with generic combinators.

I took the time to convert the example from crank's README. Compare Concur's solution below which has reusable combinators combined with minimal app-specific code, with the much more stateful code using Crank -

First we can define a generic combinator which throttles the output of a widget. This could go in a library of some kind.

function throttle(timeout, widget) {
  var isThrottled = false;
  var timer = null;
  var reset = () => {
    isThrottled = false
    timer = null
  }
  return async function*() {
    var res = yield* widget()
    while(isThrottled) {
      res = yield* widget();
    }
    isThrottled = true
    if(!timer) timer = setTimeout(reset, timeout);
    return res;
  }
}

If we wrap this around a button with a timeout 2000, the button's click will only work after a 2 second timeout.

const throttledButton = throttle(2000, async function* () {
  yield* <button onClick>Show me another dog</button>
})

We can create another generic component which can show a loading indicator for any type of async action. This could also go in a library -

function loader(axn, msg) {
  return <div>{axn()}<div>{msg}</div></div>
}

And wrap it around our Dog data loader. This component will fire off an ajax request, show a loading indicator and then show the dog image when complete -

async function* RandomDog() {
  // Get data
  var data = yield* loader(async function*() {
    var res = await fetch("https://dog.ceo/api/breeds/image/random")
    return await res.json()
  }, "Fetching a good boy...")

  // Display picture
  yield* displayView(
    <a href={data.message}>
      <img src={data.message} alt="A Random Dog" width="300" />
    </a>)
}

Finally, we want to compose a throttled button, and the random dog generator together.

forever(() =>
    <div>
      {throttledButton()}
      {RandomDog()}
    </div>)

You can see the full code, and the demo.

[brainkim]

Converting to a discussion for housekeeping purposes. @ajnsit Sorry for not getting back to you about this. Concur looks interesting but I think we might have slightly different philosophies and approaches. At a high level, I don’t really think functional programming, or at least the kind of functional programming principles that the React team advocates, is particularly important, and I value executional transparency over referential transparency in most situations.

For example, Concur components have return values and can be combined with generic combinators.

That’s an interesting approach for sure! In Crank, we treat the return of generator components as an exceptional situation where we freeze the generator on the final value. I think this is a better approach because thrown errors will also put generators in a finished state, and a generator component which returns early usually indicates some kind of bug or oversight.

Compare Concur's solution below which has reusable combinators combined with minimal app-specific code, with the much more stateful code using Crank

The idea of combinators is appealing, but I’m not sure the yield * stuff approach is the right way forward. I think there’s enough pushback and confusion just from using generators and when you add generator spreading I’m not sure people will follow.

[ajnsit]

Yup, I agree with using yield instead of yield*. Concur-js was my first attempt at translating Concur's flow idiom into Javascript and I picked a more complicated approach. I plan to make that change at some point.

Thanks for your work on Crank! I'll be watching the repo with interest, there are a lot of good ideas here and it's always interesting to see how various UI frameworks overlap.