Adaptive/responsive size?

[wishforfree]

Is this possible to specify chart size in %, such as 100% - so that it becomes adaptive - would occupy all available width within its container? If not that's greatly needed.

[leeoniya]

there's a .setSize() which you can use inside a resize handler.

see https://leeoniya.github.io/uPlot/demos/resize.html

[wishforfree]

Thanks! However. That's still a lot of code to simply tell it "be 100% of container width", don't you think so? Would be so great if you could allow % in the width init setting of the chart! Could you add it? That would be cool for peeps not well versed in javascript like me + clear and concise. Please consider! Example: const opts = { width: 100%, height: 600, title: 'Chart',

[leeoniya]

uPlot's target audience are devs who are comfortable with javascript. uPlot tries not to handle concerns outside of its own container, such as tracking the dimensions of external elements. i've also avoided providing options for legend styling and positioning because it is impossible to please everyone without introducing a ton more options and complexity. on the surface, 100% sounds easy to do because it's easy to do in CSS. but in javascript it requires a lot more code to accomplish [1] and does not work in IE11 without even more code.

if you are not comfortable with JS, you will not be happy with uPlot's lack of options for everything. thankfully, there are many other charting libs to choose from with many more out-of-the-box options: https://github.com/leeoniya/uPlot#performance

[1] https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver

[wishforfree]

I don't need it to track parent's size. Instead I want it to span parent's dimension(s) right from the start (only). Once its been initialized with parents dims it no longer needs to track parent's size (this can be achieved with the demo you posted above for whoever needs it). So something like this should do:

var canvas = document.createElement('canvas'); canvas.width = \<number>|% of parent.offsetWidth; canvas.height = \<number>|% of parent.offsetHeight;

Above doesn't result in nearly as much code as needed by the auto-resizing case (which I'm not asking for).

As a side note you are not right in restricting or limiting audience of uPlot. Plenty of cases when a server-side dev needs to quickly assemble a proof-of-concept or even MVP for which one needs to use js libs or vice-versa.

[leeoniya]

Above doesn't result in nearly as much code as needed by the auto-resizing case

and this is exactly why it will not be part of the core. the core opts & API only handles things which are NOT easy to do. as already mentioned, uPlot does not handle anything outside its own container, except absolutely necessary globals (like window scroll/resize to sync its cursor, or devicePixelRatio for drawing crisp lines).

As a side note you are not right in restricting or limiting audience of uPlot.

i wonder if you would still have this opinion after spending hundreds of unpaid hours creating, documenting, fixing/maintaining, answering hundreds of issues, creating dozens of demos and responding to tons of feature requests for your best-in-class library.

given that i have done all of these things and you have done exactly nothing for this lib (and by your github history, possibly any unpaid open source), you're in no position to tell me whether the decisions i make for this lib are the right ones. you may disagree with what i tell you, but you don't have to carry the burden of supporting all the features you're requesting, or are you volunteering to do that?

Plenty of cases when a server-side dev needs to quickly assemble a proof-of-concept or even MVP for which one needs to use js libs or vice-versa.

and i'll be happy to charge them my hourly rate if they need my help in writing the three lines necessary to get initial dims from parent.getBoundingClientRect(). i have no dreams of becoming the busiest unpaid open source maintainer and i don't think you do, either.

[wishforfree]

It's your library, you decide what to include of course, though I still think allowing to specify dims in % right from the start would not only constitute a good feature but also avoid plenty of exactly same requests in the future thus reducing your workload as unpaid open source maintainer. But that's alright - I already achieved what I wanted. Don't get me wrong I like your strive for minimalism. Thanks for offering to join, but I'm not a client-side dev. As for spending hundreds of unpaid hours developing - we, the devs, do it for the love of it don't we? Nobody is forcing you, you do it because you enjoy it. Thank you for this good library.

[leeoniya]

though I still think allowing to specify dims in % right from the start would not only constitute a good feature but also avoid plenty of exactly same requests in the future thus reducing your workload as unpaid open source maintainer

where do you draw the line?

• vue/react/angular plugins would surely help many people.
• integration with python or jupyter would help many other people (highcharts offers this).
• even more demos and more options would help people who don't know js.
• features to export the canvas in all image formats or download the data as csv or excel would surely help others still.
• ...

the list is literally endless, which is why uPlot limits its audience to js devs who are able to figure out how to do the obvious things with little additional help; i have neither the time nor the desire to answer questions about how to do frontend programming - frontend experience is a prerequisite.

As for spending hundreds of unpaid hours developing - we, the devs, do it for the love of it don't we?

i enjoy the programming, the results, getting straightforward/valid bug reports with repros, and addressing non-beginner issues. catering to a less technical (or non-frontend) audience will only serve to increase the work i don't enjoy doing.

Thank you for this good library.

you're welcome

[wishforfree]

Where above do I ask questions about how to do front-end programming? Keep your fantasies to yourself mate. I am very clear & specific what I WAS asking: a feature to specify % right from the start thus avoiding the first unnecessary rendering in the original/wrong size. I was enjoying the convo till you started to get personal in every message. You need to work on your comm skills bro - there is life outside javascript.

[leeoniya]

That would be cool for peeps not well versed in javascript like me

[wishforfree]

Precisely - indeed.

Has nothing to do with "asking questions about how to do front-end programming".

[leeoniya]

1. i addressed the question you asked in this issue.
2. you did not like the existing API to get this done, claiming that it is not simple enough for inexperienced devs.
3. i explained why it is that way, in more detail than i owed you.
4. you told me that i'm wrong.

we're done here.

thank you for your opinion.

[wishforfree]

2.a) Re: auto-resizing sample: it is simple, just inconvenient & bloated (but I didn't mean auto-resizing in the first place). 2.b) Re: allowing % in settings w/o auto-resizing: .setSize() is both simple & convenient, the reason here is more "avoiding the first unnecessary rendering in the original/wrong size"

[leeoniya]

allowing % in settings w/o auto-resizing

sigh.

if you actually had more frontend experience, you would understand that your request is not simple to implement generally. so let me ask you the difficult questions to which you almost-certainly won't have simple answers:

• what happens if the parent element is is not yet in the dom and its size is 0? this is what would happen if you are rendering uplot as part of a React component.
• what happens when the chart is rendered into a parent which must expand to the size of its contents?
• what happens when the user expects opts.width: 100% to behave like 100% in css and in fact do auto-resize?

these are just off the top of my head, and i'm sure there are a dozen more i'm not thinking of.

there are no universal or easy answers to these, and none of them are trivial to explain nor implement in a sensible manner without a ton of caveats. i'm not some stubborn idiot who likes to argue. i just know what's involved in what you're asking for and you very clearly do not.

if your use case can be solved by 3 lines which pull known dimensions from the container, it is vastly easier than what i would have to do to provide some general 100% feature that works as everyone needs.

some humility on your part would go a long way, my friend.

if you have some fundamental disagreement with the way this project is run, uPlot is MIT licensed, and the Fork button is right there for you.

[wishforfree]

That’s a better answer - finally more specific and to the point than “this library is not for you” motto of the previous answers. Now here is how you would implement it. No need in trying to cover and protect from every case of entangled web realm. Instead be plain and simple: if % is present then pull dimensions from the container whatever they are and create canvas of that size. If container dims are zeroes then be it zeroes! (or fail gracefully) The fact that container doesn’t exist/not initialized/is of zero size is completely out of scope of this lib. You don't need to care if input params/state are wrong - garbage in garbage out - just fail cleanly that's all. And docs will clearly say it doesn’t track container size after creation and refer to the resize.html demo. Absolutely no need in making it more complex than it is.

[leeoniya]

your solution is to simply ignore the obvious future support burden? that's not how this works. the current API is simple and obvious. the 100% api is filled with caveats and inconsistencies. and when someone wants to specify 100% for height? (because why on earth should it only work sometimes for for width, right?)

If container dims are zeroes then be it zeroes!

and we'll come full circle, where i'm answering questions about why 100% width or height doesnt work for the same beginner devs who don't know to write let { width, height } = parent.getBoundingClientRect(), or those like you who cannot be bothered with this huge amount of boilerplate.

you are not any closer to convincing me this is a good idea, and don't take this as a solicitation to try harder. this just isn't going to happen for all the reasons i already outlined, so perhaps "this library is not for you", because using uPlot means sometimes asking me for unpaid support, and you're burning a lot of that good will by continuing this stupid convo.

[wishforfree]

All technical issues solved long ago, your arrogant attitude is the problem here.

[leeoniya]

please go troll elsewhere.