Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lack of type safety in attributes #188

Open
joeyh opened this issue May 26, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@joeyh
Copy link

commented May 26, 2017

My first threepenny program had a bug that I was surprised was not prevented at the type level. Here it is:

import qualified Graphics.UI.Threepenny as UI
import Graphics.UI.Threepenny.Core
import Text.Password.Strength (estimate)

main = startGUI defaultConfig $ \window -> do
    prompt <- UI.input
    estimatedisplay <- UI.string ""
    getBody window #+ [ element prompt, element estimatedisplay ]
    promptIn <- stepper "" $ UI.valueChange prompt
    let showEstimate = show . (`estimate` []) <$> promptIn
    element estimatedisplay # sink value showEstimate
    return ()

The bug is that changing the value field of a UI.string has no effect, so the password strength estimate never gets displayed. The fix is changing "value" to "text".

Seems that it would be good improvement to only allow setting attributes that html elements actually have.

@HeinrichApfelmus

This comment has been minimized.

Copy link
Owner

commented May 27, 2017

Type-safe HTML elements and attributes are a good idea, but the question is whether the implementation cost in terms of additional and maybe confusing type signatures is worth the benefit. At the moment, I lean towards the "sadly no" side, but I'm happy to be convinced otherwise by a prototype implementation.

A type-safe implementation of HTML combinators has been described in the paper

"A typed representation for HTML and XML documents in Haskell "
P. Thiemann, J. Funct. Prog. 12, 2002 (2001)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.3444

Of course, one doesn't have to go the "everything type-safe" route; it's also possible to encode just a few invariants which occur often in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.