There are lots of events in my web application and I utilize the Fullcalendar library to display them. However, events get squeezed horizontally sometimes, even if there is be more space available.
Please see this screenshot of squeezed events in Fullcalendar:
As you can see, the 9:00am to 9:30am event is very wide, while four events starting at 8am are squeezed right next to it.
What could I do to prevent this squeezing? I tried changing the order in which the events are loaded into Fullcalendar, but this does not change a thing.
To be honest there's not really a lot you can do, unless you want to re-write fullCalendar's internal event rendering engine.
You can probably mitigate it a bit by setting
slotEventOverlap: true
in your calendar options - although this is the default anyway, so presumably you've already overriden it. But this will cause events to overlap each other horizontally (by up to half), thus saving some horizontal space.
More info: https://fullcalendar.io/docs/slotEventOverlap
Related
I am using react-big-calendar's month view in my app. If I have more than 2 events on the same day, the first event added stays and a "+X more" button appears (where the X is of course the number of events left for that day). This works just fine in the app, but when I try to unit test it, no matter how many events I add on the same day, the "+X more" button does not appear, and I can still access all the events of that day, even though they shouldn't be visible anymore. This is a problem for me because I have implemented some more functionality on that button which I need to test, but since I can't reach it in testing I can't even simulate a click on that.
Why doesn't this exist in test mode?
After screen.debug() I was thinking that the problem might be that the button appears when there is not enough space to display all the events, and since the testing environment simpler than the running app, works differently, there is no space check and therefore no button needed. I don't know if I am right but I still need to test it somehow.
Is there a way to access it somehow in my tests?
Events are placed in date cells according to a sort order, and the amount of space available. The 'Show more +' link only shows when there isn't enough space to place the events. Size of these cells is determined by the overall container wrapper size around your calendar, as Big Calendar uses flexbox layout. It may be that you need to apply a specific height to your container for the testing to pick it up right.
I am implementing a functionality where I can add, drag, and delete "sticky notes" on a webpage. The app is built in Vue js but it also renders content in an iframe. All the notes that are added to the page have to be on top of the iframe (which is almost 80% of the main .vue page), therefore positioning here is important and I also have to preserve the positions because I must render the notes on the same position on next page reload. The problem is that there's a lot of lag in dragging the "note" element.
The "sticky note" itself is a very lite weight separate component.
I have noticed that this because of the iframe that's present on the vue page because when I inspect the DOM in the browser and delete the iframe and then try dragging the "note" component then it works smoothly.
Things I have tried:
Use throttling: I tried to use loadsh.throttle but that does not make any difference.
Inject "sticky note" code inside the iframe: I tried to inject a sticky note element into the iframe and append it to iframe's body. It actually makes the dragging very smooth. But I don't want to go ahead with this solution because then I will have to write a lot of extra code to maintain the state of multiple notes (which can be done easily with Vue js).
In this solution, instead of using the document of the main page to attach events for dragging, I attached all the events to iframe.contentDocument.
So the question here is how do I make the drag smooth while using vue.js
Sandbox Link: https://codesandbox.io/s/affectionate-jang-3c1hw?file=/src/components/HelloWorld.vue
In this gif, the background is actually the iframe, I have reduced its opacity to hide it.
I could not actually include the iframe in sandbox code because of cross-origin problems but I have included a lot of extra content in that sandbox to make it heavy.
UPDATE:
Using the chrome task manager, I found that the page is only taking max 200MB memory and the GPU process is taking another 200MB. I am running this on a system with 16GB RAM. So I don't think it's a memory issue. But there is a sudden spike in the CPU consumption when I start dragging the element (up to 40%).
UPDATE:
I have found the fix for this problem. The actual problem wasn't lag but it was mouse trailing i.e. the draggable element wasn't able to catch up with the fast moving mouse cursor. And the slowness was due to e.preventDefault in the dragMouseDown method inside Note.vue. Just removing the e.preventDefault fixed all the problems. Also just adding a return false at the end of dragMouseDown method seems to cause the same amount of lag.
function dragMouseDown(e) {
e = e || window.event;
// e.preventDefault(); --> this line causes the mouse trailing issue
document.onmouseup = closeDragElement;
document.onmousemove = elementDrag;
// return false; --> adding this line also causes mouse trailing problem.
}
So for now I have just removed the preventDefault from this function. But I tried searching and could not find any explanation of this behavior. Also I am not sure if not cancelling the event can cause any other issue.
The problem is that you're working with mousemove without using requestAnimationFrame to debounce. Here's a working example using debounce (CodeSandbox link)
Generally, anytime you're trying to animate with javascript, you want to use requestAnimationFrame. Another thing you could try is using transform to change the position of the element instead of absolute positions.
Here's the MDN reference on requestAnimationFrame.
Here's an article by Paul Irish about using transform instead of absolute positioning to speed up a drag/drop.
As your extra description in the comments,
It starts to lag when these a lot of other content on screen. There's
a v-for in the sandbox. make it do more iterations and it will start
to laggy
The problem you met is the Dom elements were too many on your page then caused high memory usage. (Actually I tried <div v-for="i in 10000" :key="i">", then it took around 3GBs of memory), finally, everything works slowly and laggy
If your page has tons of Dom elements, you may have to consider dynamically add only visible items into the Dom tree when scrolling.
Even there are some packages that already implements this feature.
Below is one demo which uses RecycleScroller of vue-virtual-scroller:
100K items in the Codepen
You will see even the number of the items are 100,000, it still works smoothly.
PS: you may notice the below statement in the user guide of the above package=vue-virtual-scroller
The browsers have a size limitation on DOM elements, it means that
currently the virtual scroller can't display more than ~500k items
depending on the browser.
When viewing the dayGridMonth view on mobile, the squishing causes the calendar to enable a scrollbar for you to sift through.
I would like for the height to remain in full, and only the width to dynamically resize, so that you only need to scroll through the page and not the actual calendar itself (since you already do have to scroll some on the page, it's awkward). The header doesn't look too hot either but the focus right now is really on the calendar itself.
My CSS is weak to begin with, but playing with a library's styling is tenfold intimidating. Any tips in the right direction would be appreciated. Below is a sample of what the scrolling looks like (obligatory cursor because the bar fades otherwise)
Technically mobile would warrant switching to maybe week view or even day view, that solves it quick and easy, but the person i'm setting this up for really likes the full month view and wants it in all media formats to stay as is.
I located the element for the full container, but messing with height or width seems to do nothing and I can't see why.
Thanks for any help
There were two element containers manipulating the whole box content, I was editing the outer container, but the inner one needed to also be extended as it was the one where the table/rows were being populated.
I'm building a single-page website with a few sections that each fill out the user's window; I've got that working.
What I want to do is:
When the user scrolls up or down he/she would ease-up or down (accordingly) to the section before or after. My sections each have a anchor at the top of them.
Here is an example of what I'm trying to achieve. Each article fills the page. Once you scroll you jump to the next article.
http://www.made-my-day.com/
I think you could get the job done using this plugin: https://github.com/alvarotrigo/fullPage.js.
Also, it seems to be actively updated. The last commit to the repo was made 3 days ago.
Cheers!
You should take a look at scrollorama and superscrollorama.
They are lots of cool effects that you can use for scrolling, including the one just like the site you provided.
--UPDATE--
After some talking with OP, I realized that both libraries don't do what he wants.
So, my new suggestion is reveal-js, a js presentation library.
You don't really want to do this on an onscroll. Consider that onscroll isn't really anything except an event which says "the view of the page is moving".
That doesn't mean that they're using the mousewheel to do it.
On a phone, your plan can make sense: then it would be like making a drag movement equal to a swipe movement. Great.
My preferred method for scrolling is to click the middle-mouse button, and then position the mouse just below the anchor point, so that I can read each block of text as it scrolls past the screen.
I don't even need a hand on the mouse, for long blocks.
So in my case, onscroll will fire at something like 60 events/sec, and if you auto-jump the articles, I'm going to be teleporting through your entire site's content.
Other people still drag the actual scrollbar.
Listening to the mousewheel and keys (up/down, pg-up/pg-down), rather than just any method of moving the page, is safer... ...but are you sure all articles are going to be small enough so that all content fits in all browser windows, even at stupid-small resolutions (iPhone 3)?
Because if people need to scroll to read content, then all of a sudden you're dealing with a much, much more complex solution:
You would be required to listen to regular (or customized) scroll requests of any kind, to get to the bottom of the current content... ...and then you'd have to provide some sort of visual queue to the user that they are now at the very bottom of the content, and continuing to use a trigger method (swipe/drag/keys/mwheel) would switch articles.
The first two are fine... ...make it feel spring-loaded, like smartphones do.
...what about the other two, where people might expect to hit them multiple times in a second, to get where they're going?
I have a TableView in which I can scroll to view all the rows.
But I can also swipe all of those rows (when I swipe, it display some options for the row).
Currently, I'm adding a swipe event to the table view. When it's triggered, I find the appropriate row with it's index. And I do what I gotta do.
On the SDK it works well.
On a real machine though, it's very hard to get the row to swipe.
The scroll is always triggered.
I'm unfortunately afraid this could be a hardware problem and there wouldn't be anything I could do.
As Eiko mentionned, I'm not programming my application in Objective-C. But with Titanium Mobile.
His advice was right though. By setting the event in the row instead of the table, it works find :)