As per this svelte tutorial: Svelte Official Tutorials, the beforeUpdate lifecycle methods runs right before the DOM is updated. And afterUpdate runs after the DOM is updated.
They are relying on the div's offsetHeight and scrollTop to know if it should scroll to show the new content.
But how does this work in beforeUpdate ? The DOM is not yet updated so the height has not changed thus it doesn't make sense to do the calculations now.
Shouldn't this be done in the afterUpdate so the DOM is updated and we get the correct offsetHeight and scrollTop ?
Also in general (not in the context of Svelte), are these properties calculated and finalized before the DOM is rendered using the DOM tree?
You are correct about the scheduling of beforeUpdate and afterUpdate. But the Svelte tutorial code is correct anyway, because the logic is this:
In beforeUpdate, check if the scrollbar/position is near the bottom of the scroll container
In afterUpdate, only scroll to the bottom if the check in beforeUpdate returned true. This is done to not scroll to the bottom if the user scrolled up and then enters a new message - in that case, he likely wants to stay at that position.
Related
I'm struggling to create an editable grid with ag-grid. I've found that using both a renderer and editor where both have useField creates problems when removing rows with react-final-form-array.
Keep in mind that a renderer is the readonly/normal state of the cell while the editor is the edit view; Editor is only rendered while editing.
https://codesandbox.io/s/infallible-violet-joej4?file=/src/App.js
In the example above, you'll see that I've commented out the renderer and validation rules. Commenting out the renderer prevents me from displaying validation errors--on top of this, ag-grid destroys the useField, so my validations are also lost.
Naively, I thought form validation instead of field validation was the way to go, but again, I still require a custom renderer to display validations or metadata.
I then thought of creating a two dimensional array that has all of the useField cells but this causes "Rendered more hooks than during the previous render." errors. I'm not well versed in hooks but I don't see <Field> working either.
Thoughts?
Moved away from updating by cell, and instead updated by grid. This let ag-grid be the source of truth that updates final-form as needed.
I've been searching around (both on SO and around the web) to try to figure out how I can get the current height of the editor after the user has resized it. The TinyMCE 4.x docs don't show any kind of resizing event. When searching around I did come across the ResizeEditor event but that seems to apply only when objects within the editor are resized (which makes it seem like a poorly named event). Despite that, I tried to listen to the ResizeEditor event just to see and it does appear to fire whenever I resize the editor (though, I'm unsure if that's because the actual editor is resizing or because elements within the editor are getting resized, too. In any case, only the event object is passed in as an argument to the listener and I don't see any way to get the editor's current height (after the resize) from that event.
So, is there a way I can do this? To listen to the editor being resized and get its height?
thnx,
Christoph
You should be able to get the entire height of the editor (Menus, Toolbars, StatusBar, content area, etc) with code like this:
tinyMCE.activeEditor.getContainer().clientHeight
tinyMCE.activeEditor.getContainer().clientWidth
When you call tinyMCE.activeEditor.getContainer() you are getting the outermost div that contains all that makes up TinyMCE. From there it is just standard JavaScript to get the relevant dimensions of that element.
Here is an example: http://fiddle.tinymce.com/qigaab/18
I'm using the Angular UI Bootstrap typeahead to display a customized list of suggestions as the user types into a text input form control. This form control exists inside a div using jQuery slimScroll in order to maintain a constant div size despite the size of its contents fluctuating. I really hoped the typeahead would display over everything like a regular html select dropdown, but unfortunately it does not, as can be seen in this plunker. I've tried futzing around with the z-index and adjusting the position and display properties; all fruitless endeavors.
Does anybody know how to get the typeahead popup to display over its parent border? If not, is there a way I could coerce the select tag to display HTML content so I can include glyphicons, emphasized text, etc. in the list of suggestions?
The problem is with the slim scroll - you are inside a div with relative position and overflow hidden (think of it as an iFrame). There is a small workaround...
You could, essentially set the position of the generated UL (.dropdown-menu) to fixed, set a height for it, then set an overflow:scroll...
It would work in some scenarios where the input field has a fixed position... otherwise you'd need to control where the input is and adjust the position of the auto-complete to follow, and a whole other bunch of nasty scripts.
Without looking at your application, I cannot understand why your have this particular architecture, but I can say that there must be cleaner options for handling autocomplete outside of slimscroll.
I just set typeahead-append-to-body="true" on the typeahead control and it worked. Not sure exactly why, but it's certainly a simple solution.
When I use Hflex property in a included page in a MVVM approach, it doesn't work.
The problem happens when I include some page inside another, and this page has components whose sizes are controlled by hflex property. I already tried to force the rendering of the components using invalidate on parent window load, or Clients.resize(component) when it is created inside the viewmodel class, but with no success. It just happens in this case: pages included in a MVVM scenario.
Here is a way to see the error: http://zkfiddle.org/sample/3bj6e5j/9-Hflex-not-working-with-include-pages-inside-div#source-1.To see the problem, click in the "Open" label, then a combobox is shown. You can see that the size of the combobox is only updated after resizing the browser window or after clicking in the dropdown button
If I explicitly resize the browser window, then the components are correctly sized.
Could anyone give any idea on how to solve it?
It's actually the javascript who does the fault,
Let me explain more. First you set the src of the include correct.
This is before the javascript is called, and your div don't really have a width at that moment.
So it takes that size, what you see.
Then the javascript is called and and actually he show's the div, but with the rendered with of the include at that moment.
How can you fix it : use zUtl.fireSized.
Here is your working fiddle.
I'm trying to come up with way to animate a page change on a CellTable in GWT which would work the same way as changing tabs on (http://gwt.google.com/samples/Showcase/Showcase.html#!CwTabLayoutPanel). In other words the new table page would slide in from the top (or bottom for that matter).
The CellTable uses a SimplePager to initiate the page change at the moment.
Thanks, Matyas
There's no way to do that in simple way, because to make slide animation you have to have at least 2 already rendered pages: first one that is shifted out and second one that replaces first. In showcase example with animated tabset all tabs are rendered and are ready to use, but CellTable with SimplePager has no rendered pages except visible one - new page is simply rendered just directly into CellTable body.
So, if you really want to create such effect using CellTable and Pager, you have to implement your own pair of CellTable and Pager that will do following:
Keep 2 containers with rendered rows: one is visible, second is hidden.
CellTable body should have viewport (just a <div> with "overflow:hidden" CSS rule) that will have both containers inside.
When pager change page, you have to force CellTable to render new rows into hidden container.
When new data was rendered, place your hidden container into proper position to make illusion that it continues visible one, and make it visible;
Provide animation that will move both containers into new positions. I'd recommend do not use coding for animations (e.g. Timer) - much better and effective to use CSS3 transformation rules (see "CSS3 transform Property" and/or "CSS3 transition Property").
When animation finished, make first container hidden and switch pointers to visible and hidden containers - so that you return to initial state.
Hope this helps.