I was trying to fix this as a way to get to know Elm, but all it did was make me think this would be a lot easier if we could explicitly order some things (and make it highly-non-default). The general issue is that if you send the input value (as is currently done), that signal isn't zeroed out, even well after you hit enter, and if you send the signal that is cleared, it's cleared before/while the event to register a new todo is sent (so it gets an Add "" and ignores it).
I honestly have no firm idea of how to fix this, but I think if you have a
data Typing = InputHas String | Return
merge the returning stream in with the input box stream, and fold over that, you can simulate the delayed clearing. But I have no clue, just thought I'd mention because the comments/docs say it shouldn't behave this way.
I was trying to fix this as a way to get to know Elm, but all it did was make me think this would be a lot easier if we could explicitly order some things (and make it highly-non-default). The general issue is that if you send the input value (as is currently done), that signal isn't zeroed out, even well after you hit enter, and if you send the signal that is cleared, it's cleared before/while the event to register a new todo is sent (so it gets an Add "" and ignores it).
I honestly have no firm idea of how to fix this, but I think if you have a data Typing = InputHas String | Return
merge the returning stream in with the input box stream, and fold over that, you can simulate the delayed clearing. But I have no clue, just thought I'd mention because the comments/docs say it shouldn't behave this way.