Is there any elm router that works for version 0.17?
There are several of them that are not compatible with the latest release.
Thank you very much!
Apparently a router is not needed any more, according to https://github.com/etaque/elm-routing-example
Do we need routers?
I don't think so anymore, at least since Elm 0.17 and port modules, and I say that as the author of elm-transit-router, one of the three main routers for Elm 0.16.
We need packages for route parsing: that is, a way to transform the string representation of the path or hash to our app internal model. There are a few packages for this already: Bogdanp/elm-route and etaque/elm-route-parser (disclaimer: I'm the author). sporto/hop also has parsing tools but it isn't yet migrated to 0.17.
For the rest, Elm is already efficient at the job, it's just a few Msg away!
In this example I added a fancy transition effect to illustrate my point: if you implement routing by yourself, you gain more power for specific behaviours.
Note: browser history handling is done with ports for now, but it will be >easy to upgrade when the Elm bindings will be ready.
Related
I built a Vuejs App for House Plan. I've already use some optimisation way but I have two node modules whose size are far up to 20kb and I get a bad score on performance test with lighthouse on google. Here the following module :
dist\js\npm.bootstrap-vue.9bf0056f.js 228.65 KiB
dist\js\npm.vue-tel-input.4440bc34.js 181.81 KiB
Please is there a way to split this?
I initially started writing this answer as a "use async components" but I see that you have a problem with libraries that are huge (bootstrap-vue and vue-tel-input respectively), not eg. Vue Router views
Are you sure that you're importing eg. Bootstrap Vue components in an efficient way? Maybe you can avoid importing the enteriety of BootstrapVue and just use certain parts you need? https://bootstrap-vue.org/docs#tree-shaking-with-module-bundlers
See
https://github.com/bootstrap-vue/bootstrap-vue/issues/5439
As for vue-tel-input, are you using version 5? Looks like it's lighter. So hopefully it'll help you, since you can't really split someone else's library unless you fork it
https://github.com/iamstevendao/vue-tel-input/issues/213#issuecomment-764416297
I have been searching the official docs and existing questions and could not find any information on this - in Elm, how it would be possible to see the members/methods/variables that belong to or are exposed by a package in Elm, (such as the dir method in python), without having to dive into the source code each time?
What I want to do is get a simple list of what methods are exposed by an imported package. (So for a package like List, it should output reverse , all, any, map, etc.) I have attempted tab completion in elm repl and the elm extension available in VS code editor, and elm repl does not offer any methods such as help, doc, ?, dir, man, etc., so I have no idea where to even start. I'm wondering how everyone else does this other than pulling up the source code for each and every package they use.
I apologize for the newbie question and if I misread or have been missing anything, but I couldn't even find anything in the https://elmprogramming.com tutorial. Thanks in advance.
Nothing like this exists in Elm to do reflection over modules, unfortunately (as of 0.19.1, at least).
However, if you aren't looking to actually do this kind of thing at runtime, but rather as a convenient way of finding out for development, the elm packaging system enforces the requirement that all public functions are documented, so if you visit the package page, every public function and type will be documented there (obviously it can't enforce the content of the documentation, but at the very least it will be listed).
I've been struggling and very frustrated because I can't find a way to make pickadate play well with browserify. I'm migrating a Backbone app from AMD but pickadate seems impossible to work with it. I must say that I began to use browserify recently so I'm not an expert but I could migrate the rest of my code without any major incident. Of course I'm open to receive some tips and references to master browserify :)
I have jquery and pickadate installed via npm and when trying to use pickadate I'm getting the classic error:
undefined is not a function
I used this way of requiring (note the use without assigning the require to a variable):
require("jquery");
require("pickadate");
I saw this on an answer here at stackoverflow (Requiring pickadate.js with Browserify) but it doesn't work in my case.
Any help or reference about where to find help will be pretty much appreciated.
The current version of pickadate as a module only exposes the instance of PickerConstructor but it doesn't expose DatePicker neither TimePicker so every time we try to instantiate a date picker or time picker we got the error undefined is not a function because neither of them have been loaded and so no jquery.extend invocation have been made to append them to the jQuery object.
What is needed is some kind of facade / wrapper to expose all the pickadate functionality out of the box.
For this I made some small changes directly to the pickadate code base. I added an index.js that works as the facade / wrapper for picker.js, pick.date and pick.time, allowing them to be used out of the box with Browserify by issuing the typical require('pickadate'). It doesn't need to be assigned to a variable since pickadate attaches itself directly to the jQuery object. You can check this gist with the index.js code I used
This change is a copy of the way the CryptoJS library by #evanvosberg exposes its different algorithms through the same pattern implemented in its index.js file.
The only additional change would be to modify the property main in pickadate package.json to point to index.js.
I've just send a message to #amsul, the pickadate author asking for the possibility of integrate this changes directly into the pickadate github repo.
I hope people trying to use pickadate with browserify can find this solution and stop getting frustrated trying to make them play well together!
Greetings to everybody!
I started with elm yesterday and I really enjoy using it. Without any experience in front end development I could build a nice looking webpage in only 30 lines of code, which is amazing.
Now I really want to use it in a real life example, I want to build a small blog.
But I need a way to communicate with elm. For example I need to query my database and I get a list of blog entries [Blog] and now I need to pass them to elm.
I am not sure how I would do it. I was looking though the popular haskell frameworks like yesod snap and happstack and the first thing that I found was http://hackage.haskell.org/package/snap-elm-0.1.1.2/docs/Snap-Elm.html
But it seems it is intended for serving static elm files, but I need to pass arguments to it.
Any framework that you would recommend me that already has elm support for serving dynamic elm pages?
And if not, how would you do it?
My idea was just to use elm as a skeleton and then I generate a normal html file with yesod snap or happstack and integrate this file into elm. Would this be possible?
Something that would look like this
container 1000 1000 middle <| displayHtml "/pages/my_generated_html_page.html"
Edit:
My first hacky solution was this
tPage = plainText "<script src=\"http://code.jquery.com/jquery-1.10.1.min.js\"></script>\n
<script> \n
$(function(){\n
$(\"#includedContent\).load(\"/home/maik/b.html\"); \n
});\n
</script> \n
<div id=\"includedContent\"></div>\n"
Unfortunately I am not allowed to use script tags in elm.
I recommend studying elm-lang.org's source code. The majority of it is pure Elm but there are pages that are generated on the server side with Haskell.
Using the dojo toolkit, what is the proper way of locally testing code that will be executed as cross-domain, without making the actual build?
As it appears, there are three possible options (each, with their own drawbacks):
Using local (non xd) XMLHttpRequest dojo.require
This option does not really test the xd behavior, since it dojo.require[s] the js synchronously via XHR.
djConfig.debugAtAllCosts = true;
Although this option does load the required code asynchronously (via the 'script' tag), it also pulls the code in via XHR, parses the dojo.require[s] inside that, and pulls them in. This (using the loader_debug), again, is not what the loader_xd is doing. More info on this topic in a different question.
Creating a cross-domain build
This approach requires a build, which is not possible in the environment which I'm running the code in (We're using our own on-the-fly build process, which includes only the js that is necessary for a particular page. This process is not suitable for development).
Thus, my question: is there a way to use the loader_xd, which does not require an xd build (which adds the xd prefix / suffix to every file)?
The 2nd way (using the debugAtAllCosts) also makes me question the motivation for pre-parsing the dojo.require[s]. If the loader_xd will not (or rather can not) pre-parse, why is the method that was created for testing/debugging doing so?
peller has described the situation. If you wanted to just generate .xd.js file for your modules, you could look at util/buildscripts/jslib/buildUtilXd.js and its buildUtilXd.xdgen() function.
It would take a bit of work to make your own script, but you could look at util/buildscripts/build.js for pointers.
I am hoping in the future for Dojo (maybe Dojo 2.x timeframe) we can switch to a loader that just uses script tags with a module format that has a function wrapper around the module, something that is coded by the developer. This would allow the same module format to work in the local and xd cases.
I don't think there's any way to do XD loading without building and deploying it. Your analysis of the various options seems about right.
debugAtAllCosts is there specifically to solve a debugging problem, where most browsers, until recently, could not do anything intelligent with code brought in through eval. Still today, Firefox will report exception in the console as appearing at the eval site (bootstrap.js) with a line number offset from the eval, rather than from the actual eval buffer, and normally that eval buffer is anonymous. Firebug was the first debugger to jump through some hoops to enhance the debugging experience and permitted special metadata that Dojo's loader injects between the XHR and the eval to determine a filepath to the source. Webkit/Safari have recently implemented this also. I believe debugAtAllCosts pre-dates the XD loader.