It uses the official website backend, just replacing the elm.js, style.css and favicon.ico files.
You can find a brief list of new features and bug fixes in the following gist: New features and bug fixes
The main ones are:
responsive design
packages ranking
query saved in URL
sticky scrollable modules navigation bar
authors page
click function/type/operator to go to source
overflows fixed
For now, this is a just personal exploration to check bug fixes, test and improve new features, so even if some of them might potentially inspire some modifications to the official website, there is absolutely no guarantee and it seems wiser to avoid any expectation. I may also change or break things without prior notice.
One thing I miss is that elm-packages (when using the elm-package-info extension you made) has the About info shown on the side panel. I understand that won’t fit in a mobile view, but when viewing a package on a desktop screen, could that information still be shown? It’s very convenient to have that info visible immediately rather than needing to jump to another page.
A variant of the “About” page is currently in test for the official website and will most likely be available soon.
We have decided to use this approach because the information available there is mostly useful when selecting a package, but not much or not at all when consulting the documentation. As we read documentation much more than we select a package, it made sense to favor a clean and uncluttered package documentation page.
I know that in some cases, having the information available directly would be more productive, but I think overall the selected solution is a reasonable compromise.
In my case, I usually visit the package website to find some package I want to install. For reading documentation, I use intellij-elm which shows module and function documentation inside the editor so there isn’t as much of a need to visit the package website for referencing documentation.
I guess this isn’t a common use case for beginners so the compromise makes sense to show package info only in an about page.
Exactly. I understand your use case but as you guessed, this is most likely not the most common one.
Remember that Elm is minimalist in its design, and this also leaks out in some web site design decisions.
For your specific use case, maybe you could use https://elm-greenwood.com/.
All the “About” information is available directly in the search page when clicking a card, so this might be even more efficient. Packages are not ranked though and the design needs to be refined.
If some features are missing, contributions are welcome.
There is an experimental hidden feature that list all modules functions and types when entering a space in the Modules search box.
I can’t think of a better way to list those at the moment, so this was a way to introduce the feature without risking any drawback for those that don’t care about it.
Oh wow, right at the end, I think I read nearly everything but that haha. Nice!
I can’t think of a better way to list those at the moment, so this was a way to introduce the feature without risking any drawback for those that don’t care about it.
Isn’t there a big chunk of empty space on the left side? (I see that that’s not the case currently, but I swear it was when I clicked on it 5 minutes ago)
edit: yeah the site is currently not working right.
Yeah, the official website was updated, and its endpoints changed. It should be fixed now.
It depends on the width of the window, which is already pretty large for certain packages. Also, I don’t think that just having some space is a solution by itself, as some functions/types can be very big, for example Css - elm-css 18.0.0 which would push everything else a lot to the right, and I also want to avoid a cluttered interface to stay faithful to the official website.
Most of this algorithm was already done by the official website. I just fixed a few bugs, made it take a dynamic width, and allowed the layout to break lines (with an indentation) if things go wrong (zoom, bug or non-default font) or if the width is too small.
Yes, I think there is still a width computation bug remaining with records, but I have not yet had the time to investigate this one. I noticed it with Browser.application too.
I will have a look later. I should also add some fuzzy testing.
Note that the result alignment is due to word wrapping to avoid overflow. This is a last resort workaround in case something goes wrong. Here the algorithm should have used a multi-line type for convert.
Lastly the records not being aligned is due to the -> for the second one. I don’t think fixing the bug would change this, the result would be:
