DEV Community: Zenobio

An unnecessary complexity tale on Typescript-land.

Zenobio — Sat, 02 Apr 2022 05:39:13 +0000

Twitter is both a blessing and a curse as anyone who's fond of the platform can attest to. Today, I've found a small challenge lurking within a tweet under a hashtag that I don't really follow or have any interest whatsoever but sometimes it pops up (???)...

The challenger was really straight forward:

As someone who likes to keep the codebase with the small amount of any's possible, I clicked the playground link and gave it a try.

And... are those "Generics" with us in the room right now?

My first idea was pretty simple:

const f = <T extends Container<unknown>>(
  containers: T[],
  callback: (...values: any) => void
) => { ... }

Starting with a Generic T which needs to extends the Container type to guarantee that the containers parameter type is undoubtedly a List of Containers.

Now, how do we implement the type logic for ...values within the callback parameter? After some time of weird thinking and listening to some City Pop, my "amazing" head came up with this:

type FromList<L> = L extends Container<infer T>[] 
  ? L extends [Container<infer H>, ...infer Tail] 
    ? H | FromList<Tail> 
    : T 
  : never;

const f = <T extends Container<unknown>>(
  containers: T[],
  callback: (...values: FromList<typeof containers>[]) => void
) => { ... }

I know, I know, a fully fledged display of unnecessary complexity. That's exactly why I said "amazing"...

This FromList type says that, given a List of type List of Containers of something, infer the type of this something. The second validation says that, for this same given type List of Containers of something destructure it as a Tuple.

Since tuples are only lists with fixed size and known types (Weirdly close to a indexed type, don't you think so?), you can ask for this type expansion to infer the type of the first something within the Container type at the first index of this tuple while also using the spread operator to create a Tail with the remaining types.

If the first validation fails, it will return a never, a type that could not be constructed. In case it succeeds we enter the second validation. For the second validation if it fails we will just return the type of the first validation because this isn't a "tuple" it's exactly a List of Container of something and we just want this something to be our type. In case it succeeds, we will recursively create a Union which consists of the inferred type of the first something or the reduced type of subsequent FromList called with the inferred Tail type.

That's not quite right, isn't it?

If you have spent some time playing with those custom utility types in TS then you're probably aware of the problem already.

Adding this same logic to the playground we can see that first of all, TS is not happy. He's saying;

const values: unknown[]
Argument of type 'unknown' is not assignable to parameter of type 'FromList<T[]>'.

That's because we didn't gave a type to the values array which is being filled and used as parameter for our callback function. And since we typed our containers parameter as T[] and T is extending a Container of unknown, we pretty much have no way to type it correctly without using type coercions which I tend to only use on cases where I have no alternatives.

The second problem is that we're returning a Union type from our FromList and that will be the type of each and every single one of our parameters within the callback.

// value1 is of type string | number
// value2 is of type string | number
// Any value within the callback will be this union type...
f([container1, container2], (value1, value2) => {
  ...
})

We need a way to know exactly which are the types that are being held by every Container in every index of our containers parameter.

Removing the Complexity

First I want to mention that even though I've spent some time and have also used the destructured tuple in my first complex idea, I wasn't really able to move forward from there.

After this Union type I knew that an indexed type was necessary so it would be easier to retrieve the something within each Container for the given key but I wasn't able to translate it into the correct idea. Lack of experience in a case like that I assume.

I went back to the same tweet to check how people where implementing or at least how they where thinking about the problem. Found some interesting points of view but the one that caught my attention was this one from devanshj__.

Mainly because of this line;

// Changing the nomenclature for consistency
declare const f:
  <T extends Container<unknown>[]>
    ( containers: [...T],
      ...) => { ... }

If you destructure the T as a tuple as the type for the containers parameter, TS will be able to infer which are the types in each and every index of it.

Who knows why but my head wasn't capable of thinking in use the tuple this way. So, I went and updated my utility custom type to the same of the above example.

type PickFromContainer<C> = {[K in keyof C]: C[K] extends Container<infer CT> ? CT : never};

const f = <T extends Container<unknown>[]>(
    containers: [...T],
    callback: (...values: PickFromContainer<T>) => void
) => { ... }

This PickFromContainer type says; given a type C (our tuple), for each of their keys (indexes), we will check if the type in that index is of type Container of Something and if it is, we will ask TS to infer this something for us and return it as the type within the index being mapped.

That's beautiful and works like a charm. If you place that on the playground you'll see that every param on the callback function is the same type something as the Container of something in that position based on the containers parameter order.

But wait... Typescript is screaming at me again?

Argument of type 'unknown[]' is not assignable to parameter of type 'PickFromContainer<T>'

Yeah, pretty much the same, since our type T is necessarily a List of Containers of Unknown and we're pushing a bunch of Unknown to values, it's only fair that TS would consider the type of values as a List of Unknown and when we call our callback function with this list as a parameter, the PickFromContainer will not overlap the List of Unknown.

The only two things that can be assigned to unknown are any and unknown itself and that leaves us with two ways to make TS happy right now.

Be rude and say: "I don't care, it can be anything!" and Coerce the values list to any.
Be kind and say: "Hey Typescript, I know that values is unknown to you but I also know that it will be a PickFromContainer when needed".

From the start my idea was to remove any's so I'm going with the second approach.

const f = <T extends Container<unknown>[]>(
    containers: [...T],
    callback: (...values: PickFromContainer<T>) => void
) => {
    const values = [] as unknown as PickFromContainer<T>;
    for (const container of containers) {
        values.push(container.value)
    }
    callback(...values)
}

That's not my favorite approach, as mentioned before. We could have used a different approach with type predicates and let the compiled part of JS optimize it on its own but let's keep it simple and tell TS to believe us in this case. Here's the playground.

Typescript doesn't really need to be complicated - Even though it is in some cases. Sometimes we add unnecessary complexity to things and everyone have done it at least once.

Look at other developers ideas and their implementations is a really good way to improve yours. Just don't copy and paste everything, try to understand the why's and when's, because that how you'll be able to improve and derive from it when necessary.

Edit: It has been quite some time since I last saw this code and I did tried one or two extra tricks that I've learned throughout the way and it was enough to get rid of the type casting at the end. Please feel free to take a look on how I would implement the same thing today. Here's the playground link.

Trying your luck with Elm

Zenobio — Sun, 20 Mar 2022 20:50:35 +0000

Boilerplate
Baby Steps and Generators
Look at my dice, my dice is amazing!
Roll the Dice
Final Considerations
TL:DR

Some time ago I was going through interviews for multiple companies and as pretty much every developer, I've been through some weird but also some funny and thoughtful ones.

This one was on the thoughtful side and gave me some considerations while also confirmed thoughts I had from a time where I was the one interviewing.

The test was really simple;

"Implement a web app that rolls a dice with a button click and show the face with the correct number to the user."

As you can see, nothing that complex but it was funny to implement in Elm and I thought it might be good to share it for the sake of describing step by step my implementation for anyone who's trying to grasp a little bit more about the language.

Boilerplate I guess...

The first thing would be prepare the boilerplate. I won't assume you have any previous experience with Elm, will try my best to explain my thought process here from the ground up, let's go from the most basic steps then.

module Main exposing (..)

import Browser
import Html exposing (..)
Import Random

-- MAIN


main =
    Browser.element
        { init = init
        , update = update
        , subscriptions = subscriptions
        , view = view
        }

-- MODEL


type alias Model = {}


init : () -> ( Model, Cmd Msg )
init _ =
    ( Model, Cmd.none )

-- UPDATE


type Msg = NoOp


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        NoOp ->
            (model, Cmd.none)

-- SUBSCRIPTIONS


subscriptions : Model -> Sub Msg
subscriptions model =
    Sub.none


view : Model -> Html Msg
view _ =
    div [] [text "Hello World"]

Dissecting the boilerplate we have a main as the entry point that calls the init function with a Model that is just a empty Record that will be passed to the view function which will only render a div element with a Hello World text as its content.

Baby Steps and Generators

Now that we have the boilerplate let's continue with baby steps.

How will we think about implementing this "dice face randomizer"?.

Well, I tend to think towards
Behavior -> Visualization | UI -> Polishing and I'll be following those steps.

But what can we consider as behavior?

I see "generate a random number within a button click" as the basic behavior of this problem. We can implement this with a Generator.

In Elm you cannot call a Math.random the same way you can call in Javascript. It is a non deterministic behavior and as such it should be correctly handled by Elm in a slightly different way to achieve what we want. Taking a look on the documentation for the Random module it's possible to see the example below that encapsulates pretty much what we need to do.

type Msg = NewNumber Int

newNumber : Cmd Msg
newNumber =
  Random.generate NewNumber oneToTen

But what does this example says exactly?.

It says that you can call a Random.generate with two arguments, a function that returns a Msg type and a Generator of some type so it can return a Cmd Msg for you. Regarding the type annotations and the basics of how it works I think the documentation can explain it better than I'll ever be able to so please take a look for more in depth details.

We know from the documentation that Random.generate can create a Cmd Msg for us but we don't have anything useful for that in our Msg type yet, so, lets implement it to receive a randomized number:

type Msg =
  Rolled Int

oneToSix : Random.Generator Int
oneToSix = Random.int 1 6

Now we have a useful Msg but that's not enough, as you might remember the Random.Generator we have here is not something we can attach to our Msg type. It will not work since Rolled receives an Int and oneToSix is of type Random.Generator Int.

This oneToSix generator need to be called to really "generate" the value. That's a side effect and for that we need to ask Elm to perform it for us. So, now we need to use the Random.generate to generate a Cmd that Elm will gladly perform.

rollDice : Cmd Msg
rollDice = Random.generate Rolled oneToSix

That's nice, now we have a Cmd that Elm can perform and pass the value to our Msg type which will gladly update our number. Update? Do we have this update logic in place? I don't think so...

init : () -> ( Model, Cmd Msg )
init _ =
    ( Model 1, Cmd.none )

...

type alias Model = { value : Int }

...

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        Rolled newValue ->
            ({ model | value = newValue }, Cmd.none)

Now I think we're covered. Our init function was updated to initialize the Model with a default value of 1, the Model is holding a value to be rendered and the update function is receiving the newValue which will be generated by the rollDice command right?

Unfortunately not. Since rollDice is a command we need a way to trigger that and say "Hey Elm, perform this action for me".

If we look closely to the update function we can see that it returns a tuple with ( Model, Cmd Msg ), the type signature for our rollDice is a Cmd Msg.

Why not put this here on our update function since that's the way Elm transitioning from one model state to the other? Should I put that on the Rolled scope?

Put the rollDice command in the returned tuple from the Rolled Msg will trigger, every time this message have been triggered, the rollDice command. But rollDice calls Rolled and it will create a loop that freezes your application.

The correct way is to create a second Msg that will say "Hey Elm, call rollDice to me". That way the Random.generate can call the Rolled without creating a loop within our update.


type Msg
  = Rolled Int
  | NewNumber

...

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        Rolled newValue ->
            ({ model | value = newValue }, Cmd.none)

        NewNumber ->
            (model, rollDice)

Now the only missing piece is to be able to click a button to generate this number and see the number on the screen.

view : Model -> Html Msg
view { value } =
    div []
      [ span [] [ text (String.fromInt value) ]
      , br [] []
      , button [ onClick NewNumber ] [ text "Randomize" ]
      ]

Here we need to use String.fromInt since the type of the value variable is Int and the Html.text function receives a String.

You can click here to check the app till this point.

Look at my dice, my dice is amazing!

Now that we have our generator in place and we can see that it is working, it's time to start to move from the abstract behavior to the more concrete idea of a dice.

A dice face is made of dots and spaces between those dots.

That's not so helpful isn't it? We need a way to check how those dots are distributed for each one of the its faces. Just like this next picture.

Now that's helpful. We can see that the dots have a distribution that is possible to be described as lines and columns. The best way to visualize that is as if we had a Rubik's cube where every single face is white and we can paint black some of the pieces that compose each face to describe one of the dice faces.

Thats a good metaphor but you have to understand that it is mostly a description of a 3x3 matrix (Same as each single face of the Rubik's cube) and following that we will implement a matrix representation using lists to render our amazing dice.

renderDot : Bool -> Html Msg
renderDot visible =
    let
        dotClass = 
          if visible then
              "dot"
          else
              "dot__invisible"
    in
    div [ class dotClass ] []

view : Model -> Html Msg
view { value } =
    let
        renderRow lst =
            lst
                |> List.map renderDot
                |> div [ class "dots-row" ]

        rows =
            [ [ True, False, True ]
            , [ True, False, True ]
            , [ True, False, True ]
            ]
                |> List.map renderRow

        renderDice _ =
            div [ class "dice-container" ]
                [ rows |> div [ class "dice" ]
                ]
    in
    div [ class "main" ]
        [ renderDice value
        , div [ class "button-container" ] [ button [ onClick NewNumber ] [ text "Roll The Dice" ] ]
        ]

Here we're creating a really simple renderDot function that receives a boolean flag and if its True the dot will be rendered as a black spot otherwise it will be rendered as transparent so we can have the correct spacing between dots.

The view function got a little more weird but isn't that complex. We have a main div and inside that we have two containers. First one holding the renderDice function that returns a Html Msg and thus a valid children. The second container holds the button to roll the dice.

Within the let...in scope we have:

renderDice: A function that receives an argument but currently ignores it and return a Html Msg, our dice-container with the dice as its direct children.
rows: A value that calls renderRow passing a representation of a 3x3 matrix.
renderRow: A function that receives a list of boolean flag and maps every element to our renderDot function creating at the end a list of Html Msg. In that case a row containing a representation of three dots.

You can check the current state of the implementation and the whole CSS necessary to render the UI here. Please take your time to understand if needed.

Roll the Dice

The missing piece right now is connect our current functions in a way that we can check which number renders which face.

Lets firstly check what we already have that could be useful so we don't get lost within multiple moving parts.

Do you recall our renderRow function and our rows value? Let's move then out of the let...in scope so we can re-use them to build the rows automatically for us.

generateDotsFromMatrix : List (List Bool) -> Html Msg
generateDotsFromMatrix matrix =
    let
        generateDotsRow list =
            list
                |> List.map generateDot
                |> div [ class "dots-row" ]
    in
    matrix
        |> List.map generateDotsRow
        |> div [ class "dice__content" ]

Now we have changed our previous rows value to a generateDotsFromMatrix, a function that receives our matrix representation and returns the content of the dice. We also renamed the renderRow function to generateDotsRow which describes what the function does in a more clear way and renamed renderDot function to generateDot for the same reason.

That's it, only a matter of grounding some moving parts to ease our transition to a more reusable logic.

What about the other faces? This dice only renders one face...

You're right, let's fix that.

renderDice value =
    let
        dots =
            case value of
                1 ->
                    generateTruesFromMatrix 
                        [ [ False, False, False ]
                        , [ False, True, False ]
                        , [ False, False, False ]
                        ]

                2 ->
                    generateTruesFromMatrix 
                        [ [True, False, False]
                        , [ False, False, False ]
                        , [ False, False, True ]
                        ]

                3 ->
                    generateTruesFromMatrix
                        [ [ True, False, False ]
                        , [ False, True, False ]
                        , [ False, False, True ]
                        ]

                4 ->
                    generateTruesFromMatrix 
                        [ [ True, False, True ]
                        , [ False, False, False ]
                        , [ True, False, True ]
                        ]

                5 ->
                    generateTruesFromMatrix
                        [ [ True, False, True ]
                        , [ False, True, False ]
                        , [ True, False, True ]
                        ]

                _ ->
                    generateTruesFromMatrix 
                        [ [ True, False, True ]
                        , [ True, False, True ]
                        , [ True, False, True ]
                        ]
    in
    div [ class "dice-container" ]
        [ div [ class "dice" ] [ dots ]
        ]


view : Model -> Html Msg
view { value } =
    div [ class "main" ]
        [ renderDice value
        , div [ class "button-container" ] [ button [ onClick NewNumber ] [ text "Roll The Dice" ] ]
        ]

Updating our function renderDice, using pattern match to map from all the possible given values to the correct matrix that represents the combination of black and transparent dots for a given dice face.

That's it, right, a fully fledged "Roll the dice" app!!.

Yeah, if you only consider what was asked for, that's it.

But what if, for some reason, someone touches your renderDice function and changed some flags. Will be hard to track those changes just by looking at it right?. A flag doesn't mean anything by itself we can just change the renderDot function to do the opposite and voila all the app logic breaks and we will not understand easily because only the if...else was swapped and that's why using those boolean flags isn't a good idea. It's time to do some changes in order to keep us sane if we ever need to touch this code again.

type Dot 
  = Dot
  | Placeholder 

...

generateDot : Dot -> Html Msg
generateDot mDot =
    let
        cls =
            case mDot of
                Dot ->
                    "dot"
                Placeholder ->
                    "dot__invisible"
    in
    div [ class cls ] []

generateDotsFromMatrix : List (List Dot) -> Html Msg
-- Implementation remains untouched...

Created a Dot custom type that better fits the domain of the problem and did small updates in the generateDot function and in the type annotation of the generateDotsFromMatrix function.

The last change is at our renderDice function, we'll change every occurrence of True to Dot and False to Placeholder that way we can easily understand if some of the faces have something weird going on later.

That's a small change but with a big impact on how we handle our code since using this custom type helps on understand what is being rendered for each part of the face representation and catch any weird logic change.

-- Easy, the matrix that corresponds to 2.
[ [Dot, Placeholder, Placeholder]
, [ Placeholder, Placeholder, Placeholder ]
, [ Placeholder, Placeholder, Dot ] 
]

I know that everyone who's worked with Elm at a higher degree than pet projects will say that custom type should be considered and implemented from the start but I'm showing how my thought process was during this small challenge which had a specific time to finish while also trying to keep it easy to digest for people who are not really used to code with the language.

Here's the Full App.

Final Considerations

The group of people whose interviewed me was really thoughtful and easy going. They not only gave me the whole boilerplate to start with but also let me consult the documentation and even Stack Overflow if I wanted to. That's something that most technical interviews, at least that I've been through, tend to prevent you from doing.

But isn't that what we do, daily, as programmers? Check documentation, search for syntax specifics and sometimes understand how to do something through the experience of others. It should not be taken away just to see if you can hold a bunch of information that can be easily searched throughout internet. Our job should be based on problem solving not to try and hold a ginormous amount of information in our heads.

Throughout the interview the whole group was also really supportive and interactive, helping me not wander so much with the implementation details so I wouldn't throw curve balls to handle later. That's also something that a number of technical interviewers tend not to do. They see themselves as spectators, not interviewers. Pretend that they can't help you because if they do its like "cheating" but that's not the case and it's really good to see that whoever is interviewing you isn't just a static judge but a fellow developer who's capable of discuss and help you to build a better mindset for the problem while also preventing you to go down some unnecessary rabbit holes. That's what's expected from a good pair programming and what I think most interviewees want from a technical interview. They also want to be hired but that's a whole different conversation...

My final consideration is that you don't need complex problems to access someone's expertise and if you're an interviewer, you don't need to be a static judge. Strive to be someone that answer questions, pair programming and help the interviewee to feel heard and ease their concerns. I bet you can learn a bunch from them and vice-versa. Just be a fellow developer and enjoy the possibility to get to know a bunch of other developers with different backgrounds and experiences.

TLDR

A pretty simple but funny technical interview challenge with minor details that enable the interviewers to grasp the experience level of the interviewee with the language.
Full implementation

Tagged Union in React.Js with TypeScript and how to respect your props.

Zenobio — Fri, 23 Apr 2021 18:48:38 +0000

If you've ever used languages like Elm or ReasonML for writing any front-end application then you are probably familiar with the terms Tagged Union, Variants or even Discriminated Unions, but if it is not the case, let me show what i'm referring to:

-- Full code example at: https://ellie-app.com/cYzXCP7WnNDa1

-- FieldType is a Tagged union.
type FieldType
  = Editable
  | ViewOnly

init : () -> (Model, Cmd Msg)
init _ =
    (
      initial,
      (ViewOnly, "Welcome to ELM")
        |> Task.succeed
        |> Task.perform Init
    )

update : Msg -> Model -> (Model, Cmd Msg)
update msg model =
  case msg of
    Init (kind, value) ->
      (
        { model | value = value, kind = kind }
        , Cmd.none
      )

    Handle value ->
      (
        { model | value = value }
        , Cmd.none
      )


view : Model -> Html Msg
view { kind, value } =
    case kind of
        Editable ->
          div []
            [
              input [onInput Handle] []
            , h1 [] [text ("Value: " ++ value)]
            ]

        ViewOnly ->
          div [] [  h1 [] [ text value ] ]

The code above displays one of Elm's main strengths when we talk about modeling your application based on data types.

Don't be afraid of all the boilerplate, the main point here is how we have a completely agnostic view while also being 100% sure that our model can't and won't be in a undetermined state or have any missing props, never.

Our model property kind will never contain anything different from a FieldType and with the help of the Elm compiler we could rest assure that our view will also be reliable and always have all the needed data.

Typescript

Today, Typescript have been massively used as a tool which helps in minimize some runtime errors and give some guarantees about what exactly are our Data inside the sea of uncertainty that is Javascript code.

That being said, let's take a look on how commonly components are validated in some React with Typescript code bases:


// FieldType could also be just the strings values.
enum FieldType {
  VIEW_ONLY = "viewOnly",
  EDITABLE = "editable"
};

type Props = {
  kind: FieldType;
  onChange: (_: ChangeEvent<HTMLInputElement>) => void;
  name?: string;
  value: string;
};

const Field: VFC<Props> = (props) => {

// ...component implementation
};

The compiler will prevent you from use the component without the required props, but, do you really need a onChange function if you just want a non editable field?

What about any new member which enters the team, how will this component plays when someone with no deep understanding of every and each component in the code base tries to use it somewhere else?

Sure, the code above just shows a simple Field component, nothing that we couldn't reason about just reading the code, but, it is far from a good implementation if you do want to respect the props, the component behavior for each kind of implementation and how it will play when it is needed somewhere else.

Tagged Unions for the rescue.

"Talk is cheap, show me the code", Linus Torvalds

enum FieldType {
  VIEW_ONLY = "viewOnly",
  EDITABLE = "editable"
};

type BaseProps = {
  kind: FieldType;
  name?: string;
  value: string;
};

type Editable = {
  kind: FieldType.EDITABLE;
  onChange: (_: ChangeEvent<HTMLInputElement>) => void;
} & BaseProps;

type ViewOnly = {
 kind: FieldType.VIEWONLY;
} & BaseProps;

type Props = ViewOnly | Editable;

const Field: VFC<Props> = (props) => {
  const { value, name, kind } = props;
  const { onChange } = props as Editable;

  // ...component implementation
}

Now, we have some extra type boilerplate but our component props would be respected and enforced by a known FieldType just like we intended to when the component was implemented. Now, what if we try to call our component without any property? what will happen?

Well, at first, Typescript will show you an error in compile time;

Type '{}' is not assignable to type '(IntrinsicAttributes & { kind: FieldType.VIEW_ONLY; } & DefaultProps) | (IntrinsicAttributes & { kind: FieldType.EDITABLE; onChange: (_: ChangeEvent<...>) => void; } & DefaultProps)'.
  Type '{}' is missing the following properties from type '{ kind: FieldType.EDITABLE; onChange: (_: ChangeEvent<HTMLInputElement>) => void; }': type, onChange

Then,after you provide the property kind with a known FieldType, it will show you which properties you still need to provide to ensure that your component has everything it needs to work as expected:

...
Property 'onChange' is missing in type '{ kind: FieldType.EDITABLE; }' but required in type '{ kind: FieldType.EDITABLE; onChange: (_: ChangeEvent<HTMLInputElement>) => void; }'.

Now, you just need to use a mapped object or a switch case in your Field component render, which, based on the enforced prop kind and given your nullable or not nullable props enforced by the tagged union, it'll show you exactly what needs and not needs to be handled, formatted or treated.

For the sake of reusability the FieldType enum can be moved to a types/field or a types/components.

Here's an implementation for example pourposes:

Final Thoughts

IMHO that's one of the best ways to really use the Typescript compiler to help us compose code.

Not only validating our components within nullable or non nullable props values, but also helping in the proper implementation while also being thoughtful of the ones who will come to use, maintain and update the code base.

JS Sort is "weird".

Zenobio — Wed, 24 Mar 2021 05:51:54 +0000

It does not take a highly experienced JS programmer to notice that Array.prototype.sort works in his own "weird" way. But maybe you're not familiar with JS at all, in that case, let me show you what i mean by "weird":

[32, 2, 43, 101, 1025, 5].sort() 
// Result: (5) [101, 1025, 2, 32, 43, 5]

TL:DR

The sort method turns each and every value into string and then compare their sequences of UTF-16 code units values, leading to the "weird" behavior.

Not so brief explanation:

Going into MDN docs we are given the following information:

The sort() method sorts the elements of an array in place and returns the sorted array. The default sort order is ascending, built upon converting the elements into strings, then comparing their sequences of UTF-16 code units values.

Now that we know that the value is really compared as a string in UTF-16, lets check the values for our first test in this format:

[32, 2, 43, 101, 1025, 5].map(
  value => ({
    value,
    charCodeAt0: value.toString().charCodeAt(0)
  })
)

/* Result: [{…}, {…}, {…}, {…}, {…}, {…}]
0: {value: 32, unityCharCode: 51}
1: {value: 2, unityCharCode: 50}
2: {value: 43, unityCharCode: 52}
3: {value: 101, unityCharCode: 49}
4: {value: 1025, unityCharCode: 49}
5: {value: 5, unityCharCode: 53}
*/

That's nice, if you check some stackoverflow questions about how sort is implemented inside the JS motor, isn't hard to see that it's a simple std::qsort from C++ which will sort the given values alphabetically ascending if no comparison function is provided.

So if we provide a function which compare the charCodeAt0 property for our generated object, we should end with a list sorted the same way, right? Let's test it:

[32, 2, 43, 101, 1025, 5].map(value => ({
    value,
    unityCharCode: value.toString().charCodeAt(0)
  })
).sort(
  (a, z) => a.unityCharCode - z.unityCharCode
)

/* Result: [{…}, {…}, {…}, {…}, {…}, {…}]
0: {value: 101, unityCharCode: 49}
1: {value: 1025, unityCharCode: 49}
2: {value: 2, unityCharCode: 50}
3: {value: 32, unityCharCode: 51}
4: {value: 43, unityCharCode: 52}
5: {value: 5, unityCharCode: 53}
*/

Yep, is seems just like the first test.

But, which function should i use?

Having a little more understanding of how the Array.prototype.sort runs, we can pass a comparison function to handle the sort in the way we want it to:

Alphabetically ascending:

// Only Numbers:
[32, 2, 43, 101, 1025, 5].sort((a, z) => a - z)
// Result: [2, 5, 32, 43, 101, 1025]

// Only Letters:
["j", "A", "c", "D", "a", "d", "e", "k"].sort(
  (a,z) => a > z ? 1 : -1
)
// Result: ["A", "D", "a", "c", "d", "e", "j", "k"]

// Letters and Numbers:
[32, 43, 'j', 'A', 1025, 5, 'a', 'c', 'b']
.sort()
.sort((a,z) => a > z ? 1 : -1)
// Result: ["A", "a", "b", "c", "j", 5, 32, 43, 1025]

Alphabetically descending:

// Only Numbers:
[32, 2, 43, 101, 1025, 5].sort((a, z) => z - a)
// Result: [1025, 101, 43, 32, 5, 2]

// Only Letters:
["j", "A", "c", "D", "a", "d", "e", "k"].sort(
  (a,z) => a < z ? 1 : -1
)
// Result: ["k", "j", "e", "d", "c", "a", "D", "A"]

// Letters and Numbers:
[32, 43, 'j', 'A', 1025, 5, 'a', 'c', 'b']
.sort()
.sort((a,z) => a < z ? 1 : -1)
// Result: ["j", "c", "b", "a", "A", 1025, 43, 32, 5]

In case you want to take it a step further and use a custom function that could validate any of the above cases for you, there you go:

const isNumber = (v) => !isNaN(v)
const compareNumbers = (a, z, order = 'asc') => ({
  asc: a - z,
  desc: z - a
}[order]);

const compareWords = (a, z, order = 'asc') => ({
  asc: a > z ? 1 : -1,
  desc: a < z ? 1 : -1
}[order]);


const compareFunction = (a, z, order = 'asc') => {
  if(isNumber(a) && !isNumber(z)) return 1;
  if(!isNumber(a) && isNumber(z)) return -1;
  if(isNumber(a) && isNumber(z)) { 
    return compareNumbers(a, z, order)
  }

  return compareWords(a, z, order)
}

[32, 43, 'j', 'A', 1025, 5, 'a', 'c', 'b'].sort(
  (a, z) => compareFunction(a, z)
)

//Result: ["A", "a", "b", "c", "j", 5, 32, 43, 1025]

What about undefined?

Well, undefined is a edge case for sort, it will always have a bigger comparison value than any other, so it will always shown in the end of a sorted list.

It doesn't get more complex than this (no pun intended).
You can also check the String.prototype.localeCompare which is pretty good for sorting some words or letters considering that it can differentiate between upper or lower case and also accents.