Type mismatch problem for a concur-react page

I have difficulty to adjust types in a very basic Concur-React page. The program is very similar to the ajax example of Concur-React (https://github.com/purescript-concur/purescript-concur-react/blob/master/examples/src/Test/Ajax.purs).

What I’m trying to do is to dynamically load the last two columns of a table, relating to the previous cell data. So I should return an array of tds. But the compiler rejects liftAff with error:


 Could not match type

    Widget (Array ReactElement)

  with type

    Array

A minimal example can be found in this gist: https://gist.github.com/MuratOzsoyler/7fccd107916a76f37e1ae50fa239ec6d

If I return single Widget from the waitEvent function the program compiles.

Thanks in advance for your support.

The type of waitEvent is Array, so the do notation is trying to construct an array, whereas you want a Widget instead.

If I get the intent of your code correctly, I think what you are trying to do is construct a dynamic widget which has an Array of elements as the view. So a single widget is controlling some (but not all) the children of a container element. That is not supported currently.

However as a simple workaround, you can pass the surrounding elements to the widget function so it can create the DOM element itself (effectively taking control of the entire div). i.e. do something like -

waitEvent :: (Array (Widget HTML a) -> Widget HTML a) -> Widget HTML a

I put some working code here - https://gist.github.com/MuratOzsoyler/7fccd107916a76f37e1ae50fa239ec6d#gistcomment-3564778

Thank you for your quick reply. I posted my concerns there.

There is a Widget generation mechanism in concur-core. Can ve use it for this purpose? Specifically genOrr?

genOrr lets you create a container widget where the child widgets are generated dynamically in a stream. It still doesn’t seem appropriate here because it still requires controlling all the children of a div.

Note that in any case, I wouldn’t recommend using genOrr and other widget generators in Gen.purs because they are not flexible enough and won’t scale with the application without frustration.

I really recommend using only the fundamental concepts of monoidal Widget concatenation and time reification for any non-trivial apps. The other things provided, which are themselves simple functions which use the public widget API, should be considered as more of examples on how you can build your own DSL control structures that make sense for your application. If any of the provided combinators perfectly fit your application model then it’s fine, but otherwise modify them or write your own combinators from scratch. I’ve seen that that works out better in the long run.

Thank you for the explanation and help. Maybe I should restructure my design. I’ll look into it.