Replace datetimepicker

[Splines]

The previously used JQuery datetimepicker was imported like this

import css from 'jquery-datetimepicker/build/jquery.datetimepicker.min.css'
import myLib from 'imports-loader?imports=default%20jquery%20$!./../../../node_modules/jquery-datetimepicker/build/jquery.datetimepicker.full.min.js'

This dirty fix to direct webpack to the node modules folder has already caused too much pain since this was of course very fragile and thus failed often and seemingly in an undeterministic way. A quick fix was to change the import path, load the page again, then change the path back, so that webpack(er) picks up the changes. This has to find an end.

Therefore, this PR replaces the previously used JQuery datetimepicker with the Tempus Dominus Datetimepicker.

What to look for in reviews

• Check that every occurrence of the datetimepicker is working. You can find the datetimepickers here:
  • at the /lectures/:id/edit endpoint under the "Homework" section
  • at the /media/:id/edit endpoint inside the publish modal. Note that when you create an exercise, there are actually two datetimepickers in this modal! check both: only one datetimepicker (when trying to publish something different than an exercise) and both datetimepickers (when publishing an exercise)
• Errors should be shown if we try to enter a datetime string by hand and the format is not the requested one. The error should go away if a correct date is selected.
• Datetimepicker should show up when clicking in the text input field or when using the tab key to tab into this field. The Datetimepicker should also show up when clicking on the calender button. It should go away when any date is selected. It should not go away when the time is changed.
• Validation of the form when clicking on the submit button should still work, e.g. when no date is selected at all.
• Users should not be able to misuse the endpoint and make a request with an invalid date (the request should then fail). This can only be checked by making a custom request in apps like Postman etc. This should already be the case as the endpoints were not changed.
• No remnants of the old JQuery Datetimepicker should be left in the codebase.
• In the console, there should be no error: neither for the old JQuery datetimepicker, nor for the new Tempus Dominus datetimepicker.
• In the console, there should be no warnings at all. Not even related to missing sourcemaps or debug info.

Further notes

• We dropped Moment.js as library for formatting datetime strings. No frontend datetimeformatting is done anymore. The backend formatting is not affected by this.
• The javascript/packs/application.sass file is now an empty file. We cannot delete it right now as that would also mean we'd have to change the webpacker configuration which is done in another PR addressing Webpacker has been retired / Upgrade frontend bundling #454.

[codecov]

Codecov Report

Merging #526 (c0ab1a5) into mampf-next (cd3016c) will not change coverage.
The diff coverage is n/a.

❗ Current head c0ab1a5 differs from pull request most recent head b5e3fe9. Consider uploading reports for the commit b5e3fe9 to get more accurate results

@@             Coverage Diff             @@
##           mampf-next     #526   +/-   ##
===========================================
  Coverage       66.48%   66.48%           
===========================================
  Files             311      311           
  Lines            9417     9417           
===========================================
  Hits             6261     6261           
  Misses           3156     3156           

[fosterfarrell9]

I played around with it and it seems to work very nicely! I noticed the following things:

• The new datetimepicker does not yet seem to be idempotent (possibly because of the use of $(document).ready instead of the turbolinks load event. You can see this by clicking the back and forward button. Playing around in this way, you can produce dead datetimepickers in the middle of the window:
  

• Creating absurd inputs sometimes results in a javascript exception as in here:
  

• If several error messages appear, they are appended after each other, but not separated in some way:
  

[Splines]

• Dead datetimepickers (turbolink) -> fixed ✅
• absurd inputs, javascript exception -> fixed ✅
• several error messages -> ❓ cannot reproduce; how did you get both error messages to show at the same time?

[fosterfarrell9]

several error messages -> ❓ cannot reproduce; how did you get both error messages to show at the same time?

I can produce this message by using the datetimepicker for an existing homework: I modify the date like 2022-08-01 07:07 by removing a dash to 202208-01 07:07 and then click on the "Save" button.

Playing around with this I discovered another small issue: If two homeworks are edited at the same time and such an error is created for one them, hitting the save button for this one will lead to errors being displayed for the other one as well (in the example in the screenshot I hit the save button in the third row, but error messages probably destined for the third row were being displayed in the first row)

[Splines]

I can produce this message by using the datetimepicker for an existing homework: I modify the date like 2022-08-01 07:07 by removing a dash to 202208-01 07:07 and then click on the "Save" button.

Oh, good that you do such thorough testing here ;)
Now fixed ✅

If two homeworks are edited at the same time...

This is actually not related to this PR, you found an already existing bug. Note that other components are affected by this as well, e.g. try to select a wrong deletion date. The reason is in update.coffee and related files. Here, we use $('#assignment-deadline-error'), but should use #assignment-deadline-error-<%= @assignment.id %> instead. However, this means, we also have to use the ids in the HTML code which is currently not the case (it is the case for the ids of the respective elements, just not for the divs showing the error). In my opinion, this should be a separate PR.

---

Also note that there are code lines that cannot work right now, e.g. this line in update.coffee:

$('#assignment_title').removeClass('is-invalid')

There is no assignment_title in the HTML. Instead, we have assignment_title_42 etc. It does not even work when creating a new assignment. In this case id: "assignment_title_#{assignment.id}" %>, here assignment.id is empty and we have an element with id "assignment_title_" in the DOM. This is the only thing I actually fixed by adding the _ to create.coffee: $('#assignment_title_').removeClass('is-invalid'). Actually, this should be on the other PR as well, so I'm fine if you say I should restore this line of code (already done for update.coffee but not for create.coffee yet).

[fosterfarrell9]

I agree, this is a separate PR.
Everything is working very nicely now, so I will aprove. Before that, I have just one more comment (or rather a question). The turbolinks issue was fixed by adding an event listener to the turbolinks:load event which removes all stale datetimepickers. From my understanding of the turbolinks workflow, see also here or here, shouldn't it be the turbolinks:before-cache event (even if the end result ist the same)? We have also used this in our codebase multiple times in this way.

[Splines]

You can use this event to reset forms, collapse expanded UI elements, or tear down any third-party widgets so the page is ready to be displayed again.

As this is perfectly describing our use case, I've replaced it with turbolinks:before-cache, thanks for noting.

[Splines]

It'd be great if you could also check the checkboxes in my first comment of this page (hope that you can access these checkboxes and check/uncheck them, even if you're not the person that posted the comment).