Domain and Range appear to be flipped

[adamyakes]

When using Chart.Attributes.domain, I expect the x-axis to be affected, and when using Chart.Attributes.range, I expect the y-axis to be affected. However, the opposite seems to be true. The following example shows three basic charts, one unmodified, one with an increased domain, and another with an increased range, on elm-charts 3.0.0.

module Main exposing (main)

import Browser
import Chart as C
import Chart.Attributes as CA
import Html exposing (Html, div, span, text)
import Html.Attributes exposing (style)


main : Program () () a
main =
    Browser.sandbox { init = (), view = view, update = \_ _ -> () }


basicStyle : List (Html.Attribute msg)
basicStyle =
    [ style "height" "300px", style "width" "300px", style "margin" "50px" ]


chartData : List { x : Float, y : Float }
chartData =
    List.range 1 10
        |> List.map (\x -> { x = toFloat x, y = toFloat x })


chartElements : List (C.Element { x : Float, y : Float } msg)
chartElements =
    [ C.xAxis []
    , C.xTicks []
    , C.xLabels []
    , C.yAxis []
    , C.yLabels []
    , C.series .x [ C.interpolated .y [] [] ] chartData
    ]


view : () -> Html msg
view _ =
    div []
        [ span [] [ text "Unmodified" ]
        , div basicStyle
            [ C.chart
                []
                chartElements
            ]
        , span [] [ text "Increased domain" ]
        , div basicStyle
            [ C.chart
                [ CA.domain
                    [ CA.lowest 3 CA.less
                    , CA.highest 3 CA.more
                    ]
                ]
                chartElements
            ]
        , span [] [ text "Increased range" ]
        , div basicStyle
            [ C.chart
                [ CA.range
                    [ CA.lowest 3 CA.less
                    , CA.highest 3 CA.more
                    ]
                ]
                chartElements
            ]
        ]

[Arrow7000]

I've just encountered this too. I was very confused.

[Devvypaws]

We also encountered this issue. It was difficult to diagnose what was going on because our browser was constantly locking up from the workload. We were graphing a value over time, but it was trying to calculate a huge number of ticks for the time instead of the value. It's only because of this issue that we realized what was going on and were able to fix it. Turns out trying to do a ton of calculations with numbers in the billions and drawing them is CPU intensive!

[terezka]

Gosh, you are right. I was remembering my high school math wrong! Will be fixed in the upcoming version- hopefully people will not be too confused about the switch back around! Will include an upgrade guide to be sure.