You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/column-functionalities/Formatters.md
+2
Original file line number
Diff line number
Diff line change
@@ -52,6 +52,8 @@ A good example of a `Formatter` could be a timestamp or a `Date` object that we
52
52
*`Formatters.dateTimeShortUs`: Takes a Date object and displays it as an US Date+Time (without seconds) format (MM/DD/YYYY HH:mm:ss)
53
53
*`Formatters.dateTimeUsAmPm` : Takes a Date object and displays it as an US Date+Time+(am/pm) format (MM/DD/YYYY hh:mm:ss a)
54
54
*`Formatters.dateUtc` : Takes a Date object and displays it as a TZ format (YYYY-MM-DDThh:mm:ssZ)
55
+
*`Formatters.date`: Base Date Formatter, this formatter is a bit different compare to other date formatter since this one requires the user to provide a custom format in `params.dateFormat`
*`Formatters.decimal`: Display the value as x decimals formatted, defaults to 2 decimals. You can pass "minDecimal" and/or "maxDecimal" to the "params" property.
56
58
*`Formatters.dollar`: Display the value as 2 decimals formatted with dollar sign '$' at the end of of the value.
57
59
*`Formatters.dollarColored`: Display the value as 2 decimals formatted with dollar sign '$' at the end of of the value, change color of text to red/green on negative/positive value
Date sorting should work out of the box as long as you provide the correct column field type. Note that there are various field types that can be provided and they all do different things. For the Sorting to work properly, you need to make sure to use the correct type for Date parsing to work accordingly. Below is a list of column definition types that you can provide:
141
+
142
+
-`type`: input/output of date fields, or in other words, parsing/formatting dates with the field `type` provided
143
+
-`outputType`: when a `type` is provided for parsing (i.e. from your dataset), you could use a different `outputType` to format your date differently
144
+
-`saveOutputType`: if you already have a `type` and an `outputType` but you wish to save your date (i.e. save to DB) in yet another format
145
+
137
146
### Pre-Parse Date Columns for better perf
138
147
##### requires v8.8.0 and higher
139
148
@@ -149,11 +158,11 @@ The summary, is that we get a 10x boost **but** not only that, we also get an ex
149
158
150
159
#### Usage
151
160
152
-
You can use the `preParseDateColumns` grid option, it can be either set as either `boolean` or a `string` but there's big distinction between the 2 approaches (both approaches will mutate the dataset).
161
+
You can use the `preParseDateColumns` grid option, it can be set as either a `boolean` or a `string` but there's a big distinction between the 2 approaches as shown below (note that both approaches will mutate the dataset).
153
162
1.`string` (i.e. set to `"__"`, it will parse a `"start"` date string and assign it as a `Date` object to a new `"__start"` prop)
154
163
2.`boolean` (i.e. parse `"start"` date string and reassign it as a `Date` object on the same `"start"` prop)
155
164
156
-
> **Note** this option **does not work** with Backend Services because it simply has no effect.
165
+
> **Note** this option **does not work** with the Backend Service API because it simply has no effect.
157
166
158
167
For example if our dataset has 2 columns named "start" and "finish", then pre-parse the dataset,
159
168
@@ -179,7 +188,7 @@ data = [
179
188
]
180
189
```
181
190
182
-
Which approach to choose? Both have pros and cons, overwriting the same props might cause problems with the column `type` that you use, you will have to give it a try yoursel. On the other hand, with the other approach, it will duplicate all date properties and take a bit more memory usage and when changing cells we'll need to make sure to keep these props in sync, however you will likely have less `type` issues.
191
+
Which approach to choose? Both have pros and cons, overwriting the same props might cause problems with the column `type` that you use, you will have to give it a try yourself. On the other hand, with the other approach, it will duplicate all date properties and take a bit more memory usage and when changing cells we'll need to make sure to keep these props in sync, however you will likely have less `type` issues.
183
192
184
193
What happens when we do any cell changes (for our use case, it would be Create/Update), for any Editors we simply subscribe to the `onCellChange` change event and we re-parse the date strings when detected. We also subscribe to certain CRUD functions as long as they come from the `GridService` then all is fine... However, if you use the DataView functions directly then we have no way of knowing when to parse because these functions from the DataView don't have any events. Lastly, if we overwrite the entire dataset, we will also detect this (via an internal flag) and the next time you sort a date then the pre-parse kicks in again.
0 commit comments