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

Create simple, human friendly initializers #1

Closed
vojtamolda opened this issue Feb 6, 2020 · 1 comment
Closed

Create simple, human friendly initializers #1

vojtamolda opened this issue Feb 6, 2020 · 1 comment
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@vojtamolda
Copy link
Owner

Automatically code-(de)generated initializers of all traces currently accept a ridiculously large number of arguments. On average it's about 50. To make it even worse Swift requires that the arguments follow the same order as the definition. This is very inconvenient and leads to below-average user experience in comparison to other Swift libraries.

In this specific case, behavior similar Python's keyword arguments would be preferable but it would require a change to Swift that's way above my competence level. Automatic completion built into XCode that usually saves the day isn't all too helpful because the parameter list is truncated and doesn't fit the screen.

One way to reduce this friction surface is a simplified init(...) method that accepts only a handful of the most frequent parameters. The idea is similar to what convenience init(...) provides for classes.

For example, the Scatter trace could be created via a constructor that is understandable without a deep dive into the (at the moment non-existent) documentation:

init(name: String? = nil, x: XData? = nil, y: YData? = nil,
     marker: Marker? = nil, line: Line? = nil, mode: Mode? = nil)

Especially to first time users, this looks much less intimidating than the full list of 46 parameters:

init(visible: Shared.Visible? = nil, showLegend: Bool? = nil, legendGroup: String? = nil,
     opacity: Double? = nil, name: String? = nil, uid: String? = nil, ids: [String]? = nil,
     customData: [String]? = nil, meta: ArrayOrAnything? = nil, selectedPoints: Anything? = nil,
     hoverInfo: Shared.HoverInfo? = nil, hoverLabel: Shared.HoverLabel? = nil,
     stream: Shared.Stream? = nil, transforms: [Shared.Transform]? = nil,
     uiRevision: Anything? = nil, x: XData? = nil, x0: Anything? = nil, dx: Double? = nil,
     y: YData? = nil, y0: Anything? = nil, dy: Double? = nil, stackGroup: String? = nil,
     orientation: Shared.Orientation? = nil, groupNormalization: GroupNormalization? = nil,
     stackGaps: StackGaps? = nil, text: ArrayOrString? = nil, textTemplate: ArrayOrString? = nil,
     hoverText: ArrayOrString? = nil, mode: Shared.Mode? = nil, hoverOn: Shared.HoverOn? = nil,
     hoverTemplate: ArrayOrString? = nil, line: SplineSmoothedDashedLine? = nil,
     connectGaps: Bool? = nil, clipOnAxis: Bool? = nil, fill: Shared.Fill? = nil,
     fillColor: Color? = nil, marker: Shared.GradientMarker? = nil, selected: Selected? = nil,
     unselected: Unselected? = nil, textPosition: Shared.TextPosition? = nil,
     textFont: Shared.Font? = nil, xError: Shared.Error? = nil, yError: Shared.Error? = nil,
     xCalendar: Shared.Calendar? = nil, yCalendar: Shared.Calendar? = nil,
     xAxis: SubPlotID? = nil, yAxis: SubPlotID? = nil)

My gut feel is that the reduced initializer covers about 70% of use cases. More complicated charts that require tweaking of other properties can be created by crating var and modifying the rest of the properties on the following lines in arbitrary ordering:

var scatterPlot = Scatter(name: "Simpler Initializer", x: [1, 2], y: [3, 4])
scatterPlot.hoverText = ["Three", "Four"]
@vojtamolda vojtamolda added enhancement New feature or request help wanted Extra attention is needed labels Feb 6, 2020
@vojtamolda vojtamolda added this to the Plotly.swift 0.2.0 milestone Feb 6, 2020
vojtamolda added a commit that referenced this issue Feb 11, 2020
vojtamolda added a commit that referenced this issue Feb 12, 2020
- Separate Markup struct for formatting of documentation
- Better documentation for all initializers
- Simple inits only for traces
vojtamolda added a commit that referenced this issue Feb 13, 2020
- Separate Markup struct for formatting of documentation
- Better documentation for all initializers
- Simple inits only for traces
@vojtamolda vojtamolda self-assigned this Feb 13, 2020
vojtamolda added a commit that referenced this issue Feb 13, 2020
- Separate Markup struct for formatting of documentation
- Better documentation for all initializers
- Simple inits only for traces
@vojtamolda
Copy link
Owner Author

Implemented!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant