Fix date import

[Khazl]

#48

[xtheonexuk]

Please merge this ASAP

[johanneswilm]

Hey @xtheonexuk and @Khazl we actually moved away from that. We are importing the date function dynamically so that the download size is smaller for those who don't actually use that functionality. What is the usecase you have for this? You have hopefully noticed that we also offer a bundle where it has been directly included, right?

[ebrensi]

@johanneswilm funny you mention this...I have been having trouble getting Simple-DataTables to work with Google Closure Compiler because it complains that it cannot handle dynamic imports. I was trying to figure out a way around that. I suspect other people are having similar problems.

btw I am new to bundling so I am figuring this out myself. But from what I can tell, the people who use bundlers are the ones most concerned with decreasing code size, so tree-shaking will eliminate that code anyway as long as it is explicitly imported. So the dynamic import (at runtime) is not necessary, no?

[johanneswilm]

@ebrensi I was not aware Google Closure was still around. Is it still being updated? If so, I'd expect that it will support dynamic imports pretty soon. Otherwise I'd suggest to switch to something like webpack or rollup which both suport this. Browserify also seems to support it in a way, but it turns it from a dynamic import into a static one, it seems.

Dynamic imports are needed - also in this case. Before we had this I was being spammed by angry devs who didn't like that the bundle was larger than what they wanted. It's not directly related to tree-shaking. For example you can hav e a table with dates in it shown to the user. 99% of the time the user will only look at the table. Only if the user clicks on the date column to sort it, the browser downloads the extra code for sorting the table according to the date. So the other 99% of site visitors don't have to download that code at all, but you still have the logic available for those who need it.

[ebrensi]

@johanneswilm ok I see. I have also been trying out Parcel, and I was wondering why Parcel keeps creating date-xxxx.js files every time it runs. I guess it is because the date-xxxx.js file is expected to be available on demand.

I'm importing Simple-DataTables via npm, by the way.

Suppose I want to make sure my app can be used offline (i.e. "progressive" app). Then I will want to make sure everything is bundled. Is there a way I can specify which build of Simple-DataTables is bundled with my app, other than giving an explicit path, like

import * as DataTables from "./node_modules/simple-datatables/dist/umd/simple-datatables.js"

and then

const dt = new DataTables.DataTable(...)

?
It appears that is the only build that includes everything. Thanks!

[johanneswilm]

Suppose I want to make sure my app can be used offline (i.e. "progressive" app).

@ebrensi Like a PWA? What those generally do is as part of the bundling process create a list of all the static resources. So this can be several JS files, static images, css files, etc. . When the user first enters the page, the browser first downloads those resources that are requested on the first page so that it can render the page correctly, and then it downloads everything else on that list. There is a plugin for webpack called the "offlineplugin" that does this. So you both get a smaller simple database tables file which it can run from the start AND it can access the date sorting JavaScript file even if you go offline before having sued it the first time.

BTW - if you really don't want dynamic imports, take a look at this conversation [1]. I think he got it working without dynamic imports.

[1] #14

[johanneswilm]

Closing as result of dicsussion. Please reopen if you think we need to discuss this further.