I’ve been working on a small project recently to teach myself Elm: a website that finds paths between Wikipedia articles. As an example, a path from “Buzz Lightyear” to “R2-D2” might be:
Buzz Lightyear → Lego → Star Wars → R2-D2
…meaning the “Buzz Lightyear” article links to the “Lego” article, which then links to “Star Wars”, and so on.
Other people have built similar things before, with this perhaps being the most impressive example, but I haven’t seen an Elm implementation yet (let me know if there is one!).
This is the first time I’ve written anything in a purely functional language, so feedback on the code is definitely welcome! Have I done things in an idiomatic way, or are there nicer ways of modelling this kind of problem?
Also, any recommendations for how to nicely visualise the pathfinding process?
This is pretty cool. I once had to do something similar to this for a job interview.
One piece of feedback that I have re: the code is that you may want to reconsider the way you’ve split up your files / logic. It seems to be pretty common to split things up into View.elm, Model.elm, Update.elm, and etc, however, (based on my understanding) it’s not the recommended path.
Don’t be afraid to have files which feel a little bigger than what you’re used to. Elm will help you keep everything in check! For starters, I’d try/experiment moving the View.elm, Update.elm, and Model.elm into Main.elm
I had a look but I found it a bit hard to read the code with so many small files separated by messages/update/view/etc.
I’d suggest if you can to have a read at the API etiquette and implement some of the suggestions, like for example setting a specific user agent on your queries
Yup, I guess I did go overboard with the number of files . I’m used to React/Redux conventions, where having separate files for actions/reducers/components/etc is typical.
I do feel like the “hard to read” problem mostly goes away with an editor or IDE, as definitions are then all a single-click away. But it would certainly be nicer if it were readable without the help of tools like that
If I collapse pages down to a single module each, I’ll have to re-think how transitions between them work. With the current approach, one page can import another page’s Init module, which it can use to transition to that page. E.g. Setup.Update calls Pathfinding.Init to kick off pathfinding, and Pathfinding.Update calls Finished.Init when it successfully finds a path.
This approach allows the top-level update function to be trivial, as it doesn’t have to worry about transitions between pages. When I consolidate the pages down to one module each, I’ll have to add transition logic to the top-level to avoid circular dependencies between pages? And pages will also need a way of notifying the top-level when they wish to initiate a transition.
I’ll have more of a think about that…would bringing in a proper routing library solve this problem? I haven’t looked into routing much yet.
And thanks for the API etiquette link @joakin, there’s definitely some improvements I can make there! Requesting multiple articles in a single call (instead of n separate calls) is on the to-do list for example.
. I’m used to React/Redux conventions, where having separate files for actions/reducers/components/etc is typical.
And pages will also need a way of notifying the top-level when they wish to initiate a transition.