Hi, I just started using dygraphs and it's great! 😄
I noticed that dygraph-tickers.js seems to define DATEFIELD_MS, but this value is not used in any of the TICK_PLACEMENTs. It'd be great if Granularity had some values like {FIVE,TWO,ONE}_HUNDRED_MILLISECONDLY, {FIFTY,TWENTY,TEN}_MILLISECONDLY, and {FIVE_,TWO_,}MILLISECONDLY whose placements could use the milliseconds field.
On a broader note, though, as a client of the library, I wasn't able to do this myself very easily because of how the dateTicker is structured — even though getDateAxis is exported, the granularity passed to it is used to look up a value in the non-exported TICK_PLACEMENT array (and pickDateTickGranularity is also private). This might be improved by having getDateAxis accept the {datefield, step, spacing} as arguments, rather than the granularity — then users could replicate+modify the default dateTicker more easily. Just a thought 😺
Hi, I just started using dygraphs and it's great! 😄
I noticed that dygraph-tickers.js seems to define
DATEFIELD_MS, but this value is not used in any of theTICK_PLACEMENTs. It'd be great if Granularity had some values like{FIVE,TWO,ONE}_HUNDRED_MILLISECONDLY,{FIFTY,TWENTY,TEN}_MILLISECONDLY, and{FIVE_,TWO_,}MILLISECONDLYwhose placements could use the milliseconds field.On a broader note, though, as a client of the library, I wasn't able to do this myself very easily because of how the
dateTickeris structured — even thoughgetDateAxisis exported, thegranularitypassed to it is used to look up a value in the non-exportedTICK_PLACEMENTarray (andpickDateTickGranularityis also private). This might be improved by havinggetDateAxisaccept the{datefield, step, spacing}as arguments, rather than the granularity — then users could replicate+modify the defaultdateTickermore easily. Just a thought 😺