Skip to content

Conversation

@nkyllonen
Copy link
Collaborator

@nkyllonen nkyllonen commented Jan 23, 2026

Currently branches off of refactor/axis-labels-and-grid-lines. Waiting for #24 to merge first before trying to merge into philosophical-rewrite.

@nkyllonen nkyllonen changed the base branch from philosophical-rewrite to refactor/axis-labels-and-grid-lines January 23, 2026 01:07
@nkyllonen nkyllonen force-pushed the update/scales-and-tests branch from 6200dee to 0212f27 Compare January 23, 2026 01:08
@nkyllonen nkyllonen force-pushed the update/scales-and-tests branch from 0212f27 to 3e280cb Compare January 23, 2026 18:24
@nkyllonen
Copy link
Collaborator Author

nkyllonen commented Jan 24, 2026

Now that I've thought about this again, I think: no, scales should NOT support a start option since that's purely for presentation and not part of how the data is handled.

This is a possible way to keep the start attribute within the labels, but handle it within scale_values/2 and don't let it trickle down into the Scales themselves:

@doc """
Returns scale values for rendering labels and grid lines.

Supports a `:start` option to begin iteration from a specific value within the scale.

## Example

    iex> scale_values(x_axis, step: 5)
    [~D[2023-08-01], ~D[2023-08-06], ...]
    
    iex> scale_values(x_axis, step: 5, start: ~D[2023-08-03])
    [~D[2023-08-03], ~D[2023-08-08], ...]
"""
def scale_values(%{scale: scale}, opts \\ []) do
  opts = Map.new(opts)
  {start_value, scale_opts} = Map.pop(opts, :start)
  
  values = Scale.values(scale, scale_opts)
  
  case start_value do
    nil -> 
      values
    start -> 
      # Drop values until we reach the start point
      Enum.drop_while(values, fn v -> v != start end)
  end
end

Benefits:

✅ Scale protocol stays pure (only step/ticks)
✅ Presentation layer handles filtering
✅ Works with any scale type
✅ Animated demo still works
✅ Follows design doc separation
This means removing :start from DateScale, DateTimeScale implementations and just keeping it as a scale_values/2 feature.

⚠️ 🤖 This is a Claude generated suggestion however- so it still needs to be vetted and tested.

@nkyllonen
Copy link
Collaborator Author

Now that I've thought about this again, I think: no, scales should NOT support a start option since that's purely for presentation and not part of how the data is handled.

After much back and forth, I don't see a way to remove the start option from Scales.values/2 while maintaining the ability to specify a starting value. Also, I'm coming around to realizing that Scales lie at the intersection of data and presentation. The ticks option is an example of this: that is how we specify which values within a Scale we want to render. We can only do that with the data contained within the Scale. The same can be said about having a start value: we can only set a start value with the data contained with a Scale- it can't be properly done externally. Especially in conjunction with a number of ticks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant