hello = do
button [onClick] [text "Say Hello"]
text "Hello Sailor!"
inputWidget = input [(Changed <<< unsafeTargetValue) <$> onChange, Focused <$ onFocus]
inputWidget st = input [st {focusCount = st.focusCount+1} <$ onFocus
, ((\s -> st {currentText = s}) <<< unsafeTargetValue) <$> onChange]
These instances, allow a natural handling of
return values using <$>, <*>, <$, monadic
do-notation, etc
[1] https://github.com/ajnsit/concur-documentation/blob/master/R...
inputWidget = let
changeAction = do
v <- onChange
return (Changed (unsafeTargetValue v))
focusAction = do
_ <- onFocus
return Focused
in input [changeAction, focusAction]
inputWidget st = let
focusAction = do
_ <- onFocus
return (st {focusCount = st.focusCount+1})
changeAction = do
v <- onChange
return (st {s = unsafeTargetValue v})
in input [focusAction, changeAction]
Believe it or not, many Haskell programmers prefer brevity when it comes to programs like this. They're honestly not that unreadable once you learn the meaning of a few infix operators.
The things being compared don't even have the same purpose so idt comparing them even makes sense /shrug
The simplest code change turns the code in to a monadic/functor soup.
Author here.
The problem is that concur-static generates static JS code that encodes all possible UI state transitions - so if the state space is big or infinite, so will be the resulting generated JS.
I wanted to explore the viability of generating simple static UIs with some level of dynamism. concur-static is definitely not intended as a replacement for full-blown client side UI libraries/frameworks.
I understand that, but it's not like this doesn't already choke on big input spaces. Why not allow me to use a big input space with a small state space by exploring the state space instead? Otherwise you just seem to be exploiting the fact that small input spaces make for small state spaces, which seems like an unnecessary indirection.
Or is it to try to enforce small state spaces to prevent programmer error?