Blogging in Lisp


Feed Aggregator

Rendered on Mon, 17 Feb 2020 12:32:58 GMT  newer latest older 
Next udpate: Mon, 17 Feb 2020 13:00:00 GMT feeds

0.18 registry cert expired?

via Elm - Latest posts by @jorgnz on Mon, 17 Feb 2020 12:21:16 GMT

The link for 0.18 packages from points to

Earlier today that site gave me a 404, now my browser gives me a warning for a bad cert.

Just a heads-up.

Routing not working in SPA

via Elm - Latest posts by @system system on Mon, 17 Feb 2020 11:20:28 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Typesafe unified Date and Time package using phantom record types

via Elm - Latest posts by @Herteby Simon Herteby on Mon, 17 Feb 2020 11:10:25 GMT

I was thinking of reusing one of the language formats from miniBill/date-format-languages. And yup, more format functions will be needed.

Typesafe unified Date and Time package using phantom record types

via Elm - Latest posts by @TSFoster Toby on Mon, 17 Feb 2020 10:34:22 GMT

Looks really cool!

Have you had any ideas about how to handle formatting and i18n/localization? E.g. formatting the month as a string, allowing for ordinal indicators (th/rd/nd). On a related note, it might also be good to have a way to format the day number without the leading ‘0’.

Code Review: Password Form

via Elm - Latest posts by @Libbum on Mon, 17 Feb 2020 10:15:49 GMT

I’d agree that changing the logic to only compare against the first password (other than for the matching test) would simplify your entire codebase.

With that you can minimise how many times you’re throwing around the entire model, thus narrowing the scope of your functions (this is, generally speaking, something you wish to do all of the time. Saves you from using the wrong value accidentally).


pwIsUpper : Model -> Bool
pwIsUpper model =
    String.any isUpper model.password || String.any isUpper model.password


pwIsUpper : String -> Bool
pwIsUpper password =
    String.any isUpper password

You could also harden the types here, by introducing some aliases into your model:

type alias Model =
    { name : String
    , password : Password
    , passwordAgain : VerifyPassword

type alias Password = String
type alias VerifyPassword = String


pwIsUpper : Password -> Bool

which would return a compile error if you accidentally sent model.passwordAgain into this function.

This particular naming convention would collide with your current message values, but a rule of thumb with message naming could also be invoked here. You want to name your messages in a way that you explicitly understand what the message does. So UpdatePassword or even UserInputUpdatePassword could be good choices here.

I’d also look at expanding some of your variable names:

viewInput : String -> String -> String -> (String -> msg) -> Html msg
viewInput t p v toMsg = ...

It’s not so obvious what t p v refer to without digging into the rest of your code. Having more verbose variables helps with readability.

My personal taste here though is that viewInput is a redundant helper that abstracts away what you’re doing. It’s not saving you any keystrokes, adds some boilerplate and adds cognitive overhead. Others may argue about that point, and certainly this may be a helpful function if your view gets massive, but for the moment I’d drop this function.

Code Review: Password Form

via Elm - Latest posts by @paulh Paul Hollyer on Mon, 17 Feb 2020 09:49:16 GMT

You could look at your validation checks. Do you need to check against model.passwordAgain as well as model.password?

Personally, I wouldn’t do the validation check on model.passwordAgain - only on model.password. The reason being:

  1. Your messages to the user only state ‘Password must …’
  2. You have pwIsMatched in place, so when model.password passes all the validation, you know that model.passwordAgain does too if this function returns True.

If you must check both, comparing both with an || means the user will get a check mark if just model.passwordAgain passes, which doesn’t make sense to me. It may better to use && to check both pass the validation.

You have a typo in pwIsUpper, you are checking model.password twice.

You could write viewSubmitButton like so (just a suggestion):

viewSubmitButton : Model -> Html msg
viewSubmitButton model =
         disabled_ =
             not (pwLength model && pwIsUpper model && pwIsLower model && pwIsDigit model && pwIsMatched model)
    button [ disabled disabled_ ] [ text "Submit" ]

Otherwise all looks good to me.

Error Handling in Elm

via Elm - Latest posts by @system system on Mon, 17 Feb 2020 09:32:04 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Code Review: Password Form

via Elm - Latest posts by @codepadawan on Mon, 17 Feb 2020 07:58:44 GMT

Thanks to assistance in this thread, I was able to rethink my code to make it more consistent. I did not end up including the List functions, as I am not able to clearly reason my way through them yet.

As an aspiring elm programmer, I would highly appreciate it if you could review my code from the perspective of a team leader or tech lead and advise where I could improve if this was my given task and the code was to be used in production.

The reasoning I went through to code the solution the way I did was as follows:

  1. If the code was to be called more than once, place it in a function, so that it is only defined in one place.

  2. Make similar functions have the same type signature, so that one general helper function (vDrawSymbol) can call the individual helper functions (pwIsLength) consistently.

  3. Use pw for password, to shorten the code.

  4. Elm gave me the confidence to code this in a novel way, where each criteria of the password is checked as the user types.

Please have a look at this code.

Proposition: Rename max and min

via Elm - Latest posts by @palmer Palmer Paul on Sun, 16 Feb 2020 20:14:57 GMT

Published a new version of basics-extra (v4.1.0) with atMost and atLeast.

External assets drag page load speed in Elm SPA

via Elm - Latest posts by @pdamoc Peter Damoc on Sun, 16 Feb 2020 19:41:04 GMT

Using Html.Keyed on the div that holds the artifact might help.

The encoding of the elm string type

via Elm - Latest posts by @harrysarson Harry Sarson on Sun, 16 Feb 2020 19:04:24 GMT

It’s not just String.length , see “Invalid or incomplete documentation in many String functions (characters vs UTF-16 code units)”.

There is though an important difference between bugs in the elm string functions (I think this is reasonable, elm is a young langauge and “it is better to do it right than to do it now”) and the fuzziness regarding the encoding of elm strings. The former can (and will) be fixed but if the fuzzy string encoding sneaks into elm 1.0 then that fuzzyness will remain forever. (As demonstrated by windows and javascript).

Let me quote the important bit of @mattpiz’s very good link:

When passing a string from JavaScript to Rust, it uses the TextEncoder API to convert from UTF-16 to UTF-8. This is normally perfectly fine… unless there are unpaired surrogates. In that case it will replace the unpaired surrogates with U+FFFD (�, the replacement character). That means the string in Rust is now different from the string in JavaScript!

Dash docset for Elm now uses the styling

via Elm - Latest posts by @kraklin Tomáš Látal on Sun, 16 Feb 2020 18:54:16 GMT

Yeah, that’s so true. I’m quite used to the ability of searching the exact function I need from the package :smiley:

 newer latest older