jeudi 7 mai 2015

Is there a way to determine the JavaScript Date Picker library in my app that has the best performance based on reusing it

I am building a Project Management app with JavaScript on the frontend of it. I have Project Task Lists which have Task records that are opened into a Task Modal DIV when clicked on.

In the page DOM, I only have 1 Modal DIV instead of creating new/separate Modal DIV's each time a Task record is clicked on. Instead I use 1 and simply use the Task data to populate placeholder fields in the Modal when it is opened.

When the Task Modal is closed, I reset all the Task placeholder fields to an empty value so that the Modal can be re-used next time a Task record is clicked on.

Of course, it's a little more complex than simply setting some string values in the DOM and clearing them out when done. Instead there are several JavaScript libraries that have to be initiated and ran. Such as an in-line editable fields library called X-Editable which is ran on most of the Task record fields. Some other libraries ran in the Modal are a Custom scrollbar library used to make some DIV's in mty Modal scroll, such as a comment/events section.

Now I am working on adding a library for my Task Due Date field which will add a clickable Date Picker/selector calendar to easily set a Due Date value.

Sadly I have put a couple weeks into testing out what I beleive to be good light weight Date Picker libraries and trying to get them to function in the way I need them to:

  1. When Modal opens, set the Date Picker "selected date" to the value stored in the clicked on Task records data.
  2. When a user clicks the Due Date field, reveal the Date Picker which will normally be hidden.
  3. Now when the user clicks on an actual Date in the Date Picker, update all the needed DOM ares in the App with the new Date value and also save the new date with an AJAX Post to server.
  4. After that, make the Date Picker hidden again.
  5. When the user closes the Task Modal, clear out the selected Date value. Depending on the library used for the Date Picker, some allow to actually destroy() the Date Picker.
  6. Now it is ready for the next Task that is clicked on to open in the Modal and repeat the whole process.

Overall it's pretty basic, however many of the libraries I have worked with the past 2 weeks, simply could not handle certain parts of this process very easily without modifying the core library. I have found several that I was able to make work in this manner though with lots of time invested.

So out of nearly 10 Datepicker libraries, about 3-5 of them are good candidates for my app and working in the process outlined above.

So now that the background info is there, now I can present my question...

Is there a way to test or measure the performance of the remaining 3-5 Date Picker libraries that I was able to get working with all the features I need?

I have many hours invested in testing all of them and building demo apps to mock the functionality outlined about to make sure it will work in my live app.

So now I need to make a decision on which library to actually go ahead and use.

My app is a SugarCRM module so performance is important to me since SugarCRM already has a ton of JavaScript running behind what my app will be running. Also as there will be many people using this module.

So I am asking, is there some good way to measure and determine which of the libraries performs best for my app?


UPDATE

Sorry I forgot this last part...

I have 2 options to go with for setting up the Date Picker library on my Task Due Date.

  1. Option 1; Setup a Date Picker 1 time and re-use it over and over for any Task record opened in a Modal by simply switching out the selected Date values for each Task record.
  2. Option 2; Initiate the Date picker on-demand when the Due Date field is clicked on, save the record, and then destroy the Date Picker. In this 2nd method, each Task would be setting up the Date Picker on demand as needed and then killing it when done. I am really curious how these 2 options will perform different and that is why I need to measure it some how.

I have never measured JavaScript apps for performance so any guidance is helpful and appreciated. Down-votes are just as welcome but answers are even better and helpful to the community! Thanks

Aucun commentaire:

Enregistrer un commentaire