I am using Ag-grid in order to display table, i am looking to make my table responsive.
So i am trying to fit the whole table/ whole columns to what ever the width of the screen is:
If the width of the screen is less than 500px only then i want to make the the x-axis scrollable, otherwise the entire table/ entire columns should fit the screen.
Here is the codesandbox:
https://codesandbox.io/s/priceless-khorana-bw55b
Initially the table was leaving space like this:
I also tried this in mounted:
mounted () {
this.gridApi = this.gridOptions.api.sizeColumnsToFit()
}
I get below image when i reduce the width of the screen and when i have used sizeColumnsToFit():
But the sizeColumnsToFit() works fine when the width of the screen is full.
I also referred the documentation of ag-grid, and found out the below link:
https://plnkr.co/edit/YG7be1X8kAgeSEas, this is what i am looking for, and i also tried the same as example but don't know why i could not make my table responsive like that.
So, please help me in making my table fit to what ever the width of the screen is. As the width keeps decreasing and if its less than 500px only then i want to make it scrollable. Then, i also want to reduce the space between columns, so it becomes easy to fit the table.
Use the grid event gridSizeChanged to call a function each time your grid size changes. In this function, call sizeColumnsToFit to auto size your columns if your grid size is more than 500px, else, resize each of the columns to a more reasonable width each, e.g. 300px;
onGridSizeChanged(params) {
if (params.clientWidth > 500) {
this.gridApi.sizeColumnsToFit();
} else {
this.columnDefs.forEach(x => {
x.width = 300;
});
this.gridApi.setColumnDefs(this.columnDefs);
}
},
Demo.
In order to reduce the space between the columns, use defaultColDef to remove the padding from the cells, and set the padding to 0 for the ag-header-cell class for the headers
Demo.
Related
I would like to set the width of the bars to be a minimum of 12px. I would actually prefer to have a fixed width on the bars period.
As an example, when I am displaying 10 days of data, the graph looks fine, but for 30 days, it does not look good at all. Any thoughts on making this look better?
I added a horizontal scroll, but the width of the bars is automatically calculated based on the number of items in the graph, irrespective of the graph width. Is there any way to alter this behavior?
Screen capture: https://share.getcloudapp.com/yAubDN8X
Try adding [barPadding]="1" to ngx-charts-bar-vertical-2d element
<ngx-charts-bar-vertical-2d [barPadding]="1" ...>...</ngx-charts-bar-vertical-2d>
Try adding [groupPadding]="1" to ngx-charts-bar-vertical-2d element
<ngx-charts-bar-vertical-2d [groupPadding]="1" ...>...</ngx-charts-bar-vertical-2d>
as long as you minimize the padding between groups, the barWidth with grow automatically !
Say you have a UICollectionView with a normal custom UICollectionViewLayout.
So that is >>> NOT <<< a flow layout - it's a normal custom layout.
Custom layouts are trivial, in the prepare call you simply walk down the data and lay out each rectangle. So say it's a vertical scrolling collection...
override func prepare() {
cache = []
var y: CGFloat = 0
let k = collectionView?.numberOfItems(inSection: 0) ?? 0
// or indeed, just get that direct from your data
for i in 0 ..< k {
// say you have three cell types ...
let h = ... depending on the cell type, say 100, 200 or 300
let f = CGRect(
origin: CGPoint(x: 0, y: y ),
size: CGSize(width: screen width, height: h)
)
y += thatHeight
y += your gap between cells
cache.append( .. that one)
}
}
In the example the cell height is just fixed for each of the say three cell types - all no problem.
Handling dynamic cell heights if you are using a flow layout is well-explored and indeed relatively simple. (Example, also see many explanations on the www.)
However, what if you want dynamic cell heights with a (NON-flow) completely normal everyday UICollectionViewLayout?
Where's the estimatedItemSize ?
As far as I can tell, there is NO estimatedItemSize concept in UICollectionViewLayout?
So what the heck do you do?
You could naively just - in the code above - simply calculate the final heights of each cell one way or the other (so for example calculating the height of any text blocks, etc). But that seems perfectly inefficient: nothing at all of the collection view, can be drawn, until the entire 100s of cell sizes are calculated. You would not at all be using any of iOS's dynamic heights power and nothing would be just-in-time.
I guess, you could program an entire just-in-time system from scratch. (So, something like .. make the table size actually only 1, calculate manually that height, send it along to the collection view; calculate item 2 height, send that along, and so on.) But that's pretty lame.
Is there any way to achieve dynamic height cells with a custom UICollectionViewLayout - NOT a flow layout?
(Again, of course obviously you could just do it manually, so in the code above calculate all at once all 1000 heights, and you're done, but that would be pretty lame.)
Like I say above the first puzzle is, where the hell is the "estimated size" concept in (normal, non-flow) UICollectionViewLayout?
Just a warning: custom layouts are FAR from trivial, they may deserve a research paper on their own ;)
You can implement size estimation and dynamic sizing in your own layouts. Actually, estimated sizes are nothing special; rather, dynamic sizes are. Because custom layouts give you a total control of everything, however, this involves many steps. You will need to implement three methods in your layout subclass and one method in your cells.
First, you need to implement preferredLayoutAttributesFitting(_:) in your cells (or, more generally, reusable views subclass). Here you can use whatever calculations you want. Chances are that you will use auto layout with your cells: if so, you will need to add all cell's subviews to its contentView, constrain them to the edges and then call systemLayoutSizeFitting(_:withHorizontalFittingPriority:verticalFittingPriority:) within this "preferred attributes" method. For example, if you want your cell to resize vertically, while being constrained horizontally, you would write:
override func preferredLayoutAttributesFitting(_ layoutAttributes: UICollectionViewLayoutAttributes) -> UICollectionViewLayoutAttributes {
// Ensures that cell expands horizontally while adjusting itself vertically.
let preferredSize = systemLayoutSizeFitting(layoutAttributes.size, withHorizontalFittingPriority: .required, verticalFittingPriority: .fittingSizeLevel)
layoutAttributes.size = preferredSize
return layoutAttributes
}
After the cell is asked for its preferred attributes, the shouldInvalidateLayout(forPreferredLayoutAttributes:withOriginalAttributes:) on the layout object will be called. What's important, you can't just simply type return true, since the system will reask the cell indefinitely. This is actually very clever, since many cells may react to each other's changes, so it's the layout who ultimately decides if it's done satisfying the cells' wishes. Usually, for resizing, you would write something like this:
override func shouldInvalidateLayout(forPreferredLayoutAttributes preferredAttributes: UICollectionViewLayoutAttributes, withOriginalAttributes originalAttributes: UICollectionViewLayoutAttributes) -> Bool {
if preferredAttributes.size.height.rounded() != originalAttributes.size.height.rounded() {
return true
}
return false
}
Just after that, invalidationContext(forPreferredLayoutAttributes:withOriginalAttributes:) will be called. You usually would want to customize the context class to store the information specific to your layout. One important, rather unintuitive, caveat though is that you should not call context.invalidateItems(at:) because this will cause the layout to invalidate only those items among the provided index paths that are actually visible. Just skip this method, so the layout will requery the visible rectangle.
However! You need to thoroughly think if you need to set contentOffsetAdjustment and contentSizeAdjustment: if something resizes, your collection view as a whole probably will shrink or expand. If you do not account for those, you will have jump-reloads when scrolling.
Lastly, invalidateLayout(with:) will be called. This is the step that's intended for you to actually adjust your sections/rows heights, move something that's been affected by the resizing cell etc. If you override, you will need to call super.
PS: This is really a hard topic, I just scratched the surface. You can look here how complicated it gets (but this repo is also a very rich learning tool).
I am implementing a SectionList showing a list of weeks which needs to scroll to the current week, thus I am using initialScrollIndex.
The problem I face is that I don't really understand what the index given to my _getItemLayout is?
Sometimes data[index] === undefined, which doesn't make sense to me.
I need to know which section it is (data[?]) as each section contains another SectionList for the events that week, thus height isn't a constant.
_getItemLayout = (data, index) => {
const rows = (data[index] === undefined) ? 1 : data[index].data.reduce((sum, value) => value.data.length + sum, 0);
const height = (rows * 94);
return {
length: height,
offset: height * index,
index
};
}
Its been long time, but for future readers thought to share some info.
There is a good article that explains the getItemLayout, please find it here
I also faced data[index] as undefined. The reason is that index is calculated considering section.data.length + 2 (1 for section header and 1 for section footer), you can find the code here (RN-52).
With SectionList we have to be very careful while processing index.
Similar to uxxi we ended up writing up our own implementation based off of react-native-get-item-layout but there is an important distinction to make.
Wiring either method to the SectionList getItemLayout parameter re-executes the same iterations over the data for every item being rendered. The overhead added by this is substantial and after correcting for the same there is a significant performance improvement.
Essentially the key is to calculate your offset data whenever the data provided to the component changes it's shape and then call against that calculated data to obtain the offset for getItemLayout. This will result in a single iteration per data change vs endless iterations per interaction with the list.
For some reason the react-native-get-item-layout package keeps crashing with "height: <<NaN>>" so I had to write my own RN SectionList getItemLayout . It uses the same interface as the former.
Like the package it's also an O(n).
I'm working with a jsx script in Photoshop that resizes images to a specific size. The resolution is set at 200 dpi. After running the script, I can check this under Image > Image Size.
Problem is, depending on the image, it initially tends to show the resolution in dots/cm instead of dots/inch. The number itself is correct either way, but I'd like to see it mentioned there as the latter. Is there a way to realize this in JSX?
Thanks!
J
The easy way is to open your Info Panel by going to Window > Info, and then click on the x/y coordinates dropdown in the Info Panel and select inches. The dropdown is the + toward the lower-left of the panel, with the little down arrow at the bottom right of the + symbol (The plus is actually an x axis and y axis representing a coordinate plane). After that, when you check under Image > Image Size, it should show you all information in inches instead of centimeters. This should also show you inches anywhere else you look in Photoshop's interface, too, such as the rulers.
An exception would be that when using selection tools, such as the marquee tool with a setting like "fixed size" selected, you can override the units setting by typing in another unit in the Width and Height sections at the top of the window. You can even mix and match units, making a precise selection that is, for example, exactly 250 pixels (px in the Width setting) by 30 points (pt in the Height setting). And when you check your image size, it should still show you results in inches.
And finally, to answer your question as it was asked, the following code will change your rulerUnits preference without opening the Info Panel.
#target Photoshop
preferences.rulerUnits = Units.INCHES;
Note that if you want to write other scripts, you can change the rulerUnits to whatever units the script calls for, and then at the end of the script put your units back the way you had them.
#target Photoshop
// Save the original rulerUnits setting to a variable
var originalRulerUnits = preferences.rulerUnits;
// Change the rulerUnits to Inches
preferences.rulerUnits = Units.INCHES;
//
// Do magical scripty stuff here...
//
// Restore the original setting
preferences.rulerUnits = originalRulerUnits;
// List of rulerUnits settings available
// Units.CM
// Units.INCHES
// Units.MM
// Units.PERCENT
// Units.PICAS
// Units.PIXELS
// Units.POINTS
I’m trying to put together what seems to be a simple case of two NSTextFields with dynamic width and fixed spacing in between. I cannot figure out an effective way to do so though.
I’m looking to get something like this:
The blue boxes are the NSTextFields. When more text is entered into one, it should grow and thus make the other one shrink, maintaining the lead space, trailing space and the spacing in between the fields. The first one should take the priority if both of the fields have too much text. Each field will also clearly have a maximum and a minimum possible width it can reach.
How would I go around handling this, preferably utilising IB autolayout as much as possible?
It seems to me that all of constraints you mentioned directly translate into interface builder --
First view has width >= something.
First view has width <= something
Same for Second view.
Space between views is fixed.
Second view wants to be as small as possible (have its width at 0) but this has lower lower priority than the previous constraints and lower priority than inner content size constraints.
The code I had to add to my view controller, after applying the constraints as per the ilya’s answer:
In controlTextDidChange (_controlWidthConstraint refers to the fixed width constraint of the input; it’s probably 0 by default for the second input):
// Get the new width that fits
float oldWidth = textControl.frame.size.width;
[input sizeToFit];
float controlWidth = textControl.frame.size.width;
// Don’t let the sizeToFit method modify the frame though
NSRect controlRect = textControl.frame;
controlRect.size.width = oldWidth;
textControl.frame = controlRect;
_controlWidthConstraint.constant = controlWidth;
The key lies in invalidating the intrinsicContentSize for the text field when text is input.
You can check a sample project here, to get you on the right track.