my project is a scrollable scheduler, similar to vis-timeline and using Vue.js.
One of my biggest problems is how to scroll infinitely and smoothly in every direction (past and future).
I'll readily admit that I'm not that experienced as a programmer yet, so I'd appreciate it if you'd check and evaluate my approach.
My solution currently looks like this:
JS:
let datelist = [yesterday, today, tomorrow]
HTML:
<div v-for="date of datelist">
<div width="100%" height="100%">{{date}}</div>
</div>
Because 3 divs take up 300% of the screen, an overflow occurs (scroll bar visible). After rendering, I centre the middle one (today).
While scrolling via drag&drop and 50% of the previous or following day is visible, an event is triggered that modifies the datelist:
Scrolling to the left:
*Generate previous day of yesterday and remove tomorrow *
datelist = [yesterday -1 day, yesterday, today]
Scrolling to the right:
*Generate following day of tomorrow and remove yesterday *
datelist = [today, tomorrow, tomorrow + 1]
However, this also has a few disadvantages:
Every time the list changes, it has to be completely re-rendered. If each day gets a lot of content later (appointments), this could cost performance.
You can actually only scroll linearly, as soon as I want to jump to a date, for example with a date picker, I have to recreate the whole list.
Maybe more ?
How would you solve the problem?
I am more concerned with the way to solve the problem than with a solution.
Constraints:
No third-party libs
high performance
easy
Using IntersectionObserver is your go-to here. Thanks to it, you will be able to set various behavior, fetch content and allow for interactivity regarding the other "date cells".
The useIntersectionObserver composable is a good candidate for such a purpose.
Only displaying what is currently visible can also be helpful, so that you don't have too much content in the DOM. This may help but can also be done yourself (check the source code there).
I'm not sure why your list needs to be re-rendered but maybe consider not nuking the whole thing and applying some modifications at the given locations.
Or use a memoization approach, depending on what you need to memorize it may be quite quick to implement yourself.
With the given approaches listed above, you may not even need to remove dates from your list, just hide (CSS) or let it off the screen. Aka rather than having let datelist = [yesterday, today, tomorrow], consider having let datelist = [..., x , y, today, z, a, b, ...] each time you reach a boundary.
TLDR: for your constraints, you can pick only 2 from the 3.
Related
Last year I tried to learn a bit React JS for making the project you can find here. I apologize for my rather vague / imprecise description below, but I'm by no means versed in this.
Basically, there is a single <svg> tag, which will contain a number of paths etc. as created by the user. The problem I have is that things become very slow the more paths are present. To my current understanding, this is due to the fact that the entire SVG DOM gets updated repeatedly upon user interactions that involve dragging the mouse or using the mouse wheel.
This holds true, particularly, for two user interactions:
a) Panning - all paths are being moved at the same time; I think one might circumvent this issue by taking a snapshot image first and moving that around instead. However, that's not a solution for the other user interaction, which is:
b) Expanding/collapsing paths - here, all paths are being modified in terms of coordinates of some of their points. That is, every path must be modified in a different way, but all of them must be modified at once, and this must happen repeatedly because it's a user interaction controlled with the mouse wheel where changes happen gradually and the user requires immediate visual feedback on these changes as they happen.
Particularly for b), I see no alternative that would involve a single transformation or something.
After extensive research last year, I came to the conclusion that choosing SVG to display and modify a lot of things dynamically on screen was a wrong decision in the first place, but I realized too late, so I gave up and have never touched it since. I'm pretty certain that there isn't any way to deal with the low performance that builds upon what I already have; I have no intention to start this project from scratch with a completely different approach. Also, the reason why I chose SVG was that it's easy to manipulate.
In summary, I'd basically like to get confirmation that there is no feasible way to rescue this project.
I'm not looking for the height of every row in my month view in FullCalendar to be the exact same height; I just want to be able to see the full content of every cell in the calendar.
contentHeight: 'auto'
doesn't appear to solve anything in this view, and adjusting the contentHeight to a specific integer adjusts all rows evenly, which makes the calendar unnecessarily huge if it's just one particular cell, and thus row, that needs to be bigger to display all events.
Additionally, it appears that I'd have to figure out how big to set contentHeight in a fairly complicated manner, as 'auto' doesn't appear to make adjustments for additional events on one particular date.
It's easy to reproduce by adding around 10 events to one date, and setting contentHeight to 'auto'.
Is there any way to make this work?
I'm not really sure how you expected contentHeight to help you in this case, since the documentation makes clear that this affects the whole calendar area, not just individual rows.
You haven't made it entirely clear, but it sounds like you're trying to deal with a scenario where you have a lot of events on one particular day, and would like the calendar to expand the height of that row so they are all visible.
As far as I can observe, the calendar will do this for you by default. See this demo: http://jsfiddle.net/7nsbjya5/1/ . There are 9 events all on one day, and no events elsewhere in the month. The row on which the events occur is automatically expanded to accommodate them.
The only way I can see where this would not happen is if you had set the eventLimit value to something other than its default.
e.g. if you set
eventLimit: 3
then the calendar will never display more than 3 events in any cell, and will replace the others with a link where they are then displayed in a popover when clicked.
Whereas, if, as per my demo, if you either do not set eventLimit, or set it to
eventLimit: false
(which is the default anyway) then you should have no problem. You also should not have any need to set any value for contentHeight, unless you wish to use it for its stated purpose instead. Either way it has no effect on the height of individual rows.
N.B. If that isn't your problem, then you'll need to update your question with enough relevant code for us to be able to diagnose the exact issue. A screenshot of your problem might also be helpful.
I have a high interest in creating my own event calendar/scheduler for my site and found Bootstrap Calendar, it has real potential. I looked at dhtmlxScheduler but its hard to customize the look, it has a lot of nice features though. I have a Fullcalendar now and I like the new Scheduler but I still want a more custom look and some custom functionally.
My JS/Jquery is limited so it makes it difficult to get a real picture of BS-Cal layout and unfortunately there seems to be little documentation other than comments in the code.
So my issue with BS-Cal is the event ordering/stacking in the week view.
The Question - Can the events be reordered in a per day list like the 2nd photo below.
So far - I see the offset class for the columns and the events but the events seem to be wrapped in a "row" div which forces a single "list" for the whole week rather than per day placement order left to right on the table.
Here is what I believe is happening:
This is what I'm hoping to accomplish:
I would like to ask if there are any examples related to Polymer's animated pages ( http://www.polymer-project.org/docs/elements/core-elements.html#core-animated-pages ) and how we can build a similar demo using the resources provided in the Angular/material repo (https://github.com/angular/material).
I would like to achieve http://www.polymer-project.org/components/core-animated-pages/demos/music.html but I don't want to use Polymer since I would like to use Angular.
Can you please provide me some directions in order to start?
What they typically do with Polymer is have two connected elements which shows only one and when you perform some action, the other gets shown (from display: none) and animates from certain dimentions to its final form. Sometimes elements also shift but it depends on whether the content is able to move to its new position or not.
You have to work with css transition, transform and display. Sometimes even custom animations. And you are mostly changing multiple divs to their final form. I think the most difficult would be animating colors (from white to pink or from yellow to green for example) as those are most difficult to do (performance-wise).
If you look at the example you've set (final link) you see there's a list of items with a detail div and once you click the item you show the detail and transform the contents to its final dimentions.
Just know that these things are pretty hard if you aren't very much into Angular or HTML/CSS/Javascript.
The framework of Polymer for Web is very much a work in progress and i wouldn't be surprised if it took a few months to get similar results for both native and web.
You can take example from things like this: https://medium.com/tictail-makers/giving-animations-life-8b20165224c5 or https://www.polymer-project.org/apps/topeka/ or http://codepen.io/collection/amheq/ . And don't forget to speed it up by using some bootstrap theme like this http://fezvrasta.github.io/bootstrap-material-design/ or something.
I've been struggling with the same problem as there isn't much to go from right now. You stated the Angular project but that will take time. If you want to do it now, you have to do quite some work (if you do, share it with us), but you might be better of with postponing this until most of the bugs and problems have been solved.
Thats what i'm doing now.
I previously asked this question a few days ago, but I do not think anyone besides paxRoman actually figured out what I was asking, as it was hard to describe without an example.
We did however manage to figure out what might be my problem, and I managed to put the code up on bl.ocks.org so you can see an example of what I mean!
Here is the example: http://bl.ocks.org/3020018
Each time the data is refreshed (in this example, just read from a json file), all the nodes are re-created and re-added to the drawing.
What I want to happen
I want the nodes to update without moving at all.
If a new node exists in the new array, it should just appear like they all do now, if something exists in the previous array but not in the new, it should simply disappear.
As you see in the example, that is not what is happening and I have not been able to figure out why for the past week.
So my question is:
What am I actually doing wrong? Is it my lack of links? What is the problem? The two of us spent over an hour looking at this yesterday and could not make sense of it, I have spent a good week on it now without much progress :/
My old question/post is still up, but it's badly formulated and I had no example to show.
Thanks for helping me :)
So, I am pretty sure I have solved most of my problems!
It came down to how I was adding/modifying the nodes when updating the data. I completely forgot about x/y and similar attributes since I did not set them myself, so I was adding "new" objects every time I updated the data, even if they weren't actually new.
With some jQuery magic using $.extend() I have sort of gotten it working, but it's still slightly moving/pulsing whenever I update the data.
I updated the gist to show the changes. http://bl.ocks.org/3020018
I would still like to remove that little pulsation too, so let me know if you have any ideas :)
Have you tried setting the friction parameter (where you have the linkDistance and charge set)? Setting it to 0.9 will speed up finding the final position as I think it defaults to 1 if not set. Its simply a case of adding
.friction(0.9) // or any suitable value closer to 0 - have a play!
Hope that helps