`Config.jsExtraDirs` field for serving local directories.

[duplode]

So I set out to tackle #110, but on reading the relevant code I noticed that on 0.6 you removed all Threepenny-specific sever state. Rather than reintroducing it, I figured out it would be easier to just allow for serving directories other than jsStatic through Config, which is good enough for my purposes at least.

Debatable decisions (I will happily make any adjustments you deem necessary):

• jsExtraDirs is a [(String, FilePath)] because that seems to be the simplest thing that works. Exposing the paths directly without the alias would lead to ugly URLs in the browser, and also make unpleasant filepath-to-URL sanitising by library users necessary more often.
• Given the aliases, the /dir prefix is arguably unnecessary. The one tangible advantage in keeping it is that it stops users from accidentally overwriting the /static route...
• I reintroduced the utf8-string dependency, as the functionality it provides is needed for handling Unicode in aliases correctly.

This gist is a minimal demo of the patch.

[HeinrichApfelmus]

I am undecided. I tend towards the idea that it may be a better idea to allow dynamical loading of extra files, i.e. to bring back loadFile or loadDirectory in some form.

[duplode]

I tend towards the idea that it may be a better idea to allow dynamical loading of extra files, i.e. to bring back loadFile or loadDirectory in some form.

That would be an excellent reason to reject this PR :smiley: jsExtraDirs ends up requiring slightly uncomfortable amounts of path and URL mangling, making it less convenient than loadFile and loadDirectory. Naive usage of it also runs into the image caching annoyance mentioned in the SO question linked from #110. Therefore, +1 for bringing back dynamic loading if you feel it is the best idea. In the meantime, I can keep using this branch for my programs.

[HeinrichApfelmus]

Oh, right, caching was a problem. I will try to add loadDirectory back in.

I have to ask: What exactly do you mean with URL mangling? That you have to append the string static in front? I am unsure whether that is a good or a bad thing. The problem with load* is that the URL is generated automatically, but you have to keep it around as a parameter, which can also be annoying.

[duplode]

I have to ask: What exactly do you mean with URL mangling? That you have to append the string static in front? I am unsure whether that is a good or a bad thing.

IMO the static prefix is definitely a good thing. The mangling I referred to is something significantly more annoying: Windows paths use backslashes. Therefore, if you care about Windows you can't just take a path fragment you used a moment ago in writeImageFile and plop it into the corresponding URL, as it will have backslashes instead of forward slashes. You need to either replace the backslashes or save the path components separately so that they can be reassembled.

(Secondarily, the # suffix workaround for the caching issue might also fall under "URL mangling".)

The problem with load* is that the URL is generated automatically, but you have to keep it around as a parameter, which can also be annoying.

In some scenarios perhaps, but with my usage patterns that is not much of an issue. I would not know paths or URLs of the served files in advance (the files are typically created in temporary directories, with file names partly determined by user input), so I would have to store them anyway. Before switching to jsExtraDIrs, my strategy was sending the paths to the Threepenny layer through the monadic stack and then only creating the URLs with loadFile at the last moment, right before making the img/a elements that would hold them.

[HeinrichApfelmus]

Sorry for the long wait. 😅 I believe I have fixed #110 now. Does this mean that this PR can be closed?

[duplode]

Does this mean that this PR can be closed?

Yes, it does! 😃