Convert templates (*.tt) to Elm

[domenkozar]

I've been working on smaller improvements at Hydra frontend side. I think we have to change our infrastructure there with a better tooling so we can advance easier.

I propose to use functional programming DSL for frontend called Elm. This is not a discussion what tool to use, but merely a proposal how to improve Hydra by volunteering to do the job.

Elm compiles to JavaScript, so it can call native functions and shouldn't be a limit to what we can do. Google can index JavaScript sites these days.

What is Elm language?

Elm is a functional programming language for declaratively creating web browser-based graphical user interfaces. Elm uses the functional reactive programming style and purely functional graphical layout to build user interface without any destructive updates. - wikipedia

In essence, you craft HTML using functions and model (state of the app) and output HTML + some types to note signals. Then update function as small finite state machines takes current model (state of the app) and signals (which can contain data) and they trigger some other events (like http requests, etc) and output the new state (model).

More at http://guide.elm-lang.org/architecture/index.html

Example fetching HTML and rendering it based on button click http://elm-lang.org/examples/http

Motivations

• it's really hard to follow the templating model currently used and be sure there're no errors in the template (example: missing tag would be caught by Elm where it currently isn't)
• UI has been pretty much left as-is (last commit I see was an attempt to port it to bootstrap 3)

Benefits

• Hydra API returns JSON. This as itself is not a goal, but making cli clients and libraries for communicating with Hydra will be much easier
• A lot of type checking to catch errors. No missing HTML tags, basically the UI can only fail if the model has incorrect data/state
• Frontend (development) is decoupled from backend. We could have some fixtured json files serving with a simple HTTP server to develop the UI. No need to setup the whole machinery to change frontend
• More contributions - this is very subjective, but I think when we have well defined workflow for frontend, we'll also get more contributions
• Future improvements will be eaiser. That means, Elm makes it easier to load resources on the fly (for example 1000+ failed builds) as by design allows such things contrary to template files where you have to manupulate DOM with javascript

Scope

I'm volunteering to lead this work. Scope is something like:

$ cat src/root/*.tt | wc -l
4049

and converting server side rendering to output JSON instead of html.

Feedback

I'd like inputs from others and mainly @edolstra if he thinks this is reasonable. I've recently converted a very small app to Elm and proved it's really easy and pleasant to work with.

[edolstra]

Getting rid of Template::Toolkit (and Catalyst/Perl for that matter) sounds great to me. I don't have experience with Elm though so I can't comment on whether using that is a good idea, but it looks pretty nice. Maybe you could do a proof-of-concept of a couple of Hydra pages (maybe adding more server-side JSON APIs if needed)?

[domenkozar]

@edolstra sounds good! I'll work on a prototype and look what JSON APIs we currently support. If you want I can give you a tour of Elm.

Note: also addresses #108

[domenkozar]

I implemented the very first index page today. Satisfied with the result.

Code: https://github.com/domenkozar/hydra-frontend

Here is what happens:

• npm run dev triggers webpack-dev-server in package.json
• webpack-dev-server reads webpack.config.js, which is responsible for collecting resources and processing them
• webpack loads bootstrap, etc but eventually uses src/index.js as main javascript entrypoint
• webpack also uses src/index.html file at the root of dist/ which is served
• webpack uses Elm loader that processes src/Main.elm to JavaScript and is included in dist/app.js loaded by index.html
• src/Main.elm glues all pieces Elm together
• src/Models.elm contains Algebraic datatypes used as state throughout the app
• src/View.elm generates Html markup
• src/Update.elm handles messages with data and mutates the model (this is what I'l tackle next, instead of using hardcoded initial model, I'll get the data from Hydra API)

[domenkozar]

cc @civodul as this is also relevant for Guix

EDIT: missed close button

[domenkozar]

I've deployed a demo app to http://hydra-frontend.domenkozar.com/. Note that nothing is coming from Hydra backend yet.

[Ericson2314]

Looks great; Let's get this deployed!

[rbvermaa]

Good work @domenkozar. However, I think having the jobsets listed in the frontpage is not a good idea. Our company hydra instance has about 250 jobsets in 30 different projects, showing them all (or any even), really takes away the overview of the different projects.

[domenkozar]

@rbvermaa I didn't know exact numbers you have, but I was aware of this edge case. Thanks for letting me know, I'd like to fix this in the begining.

I'd like to understand better how you use Hydra and what would be the best workflow/UX for you.

My ideas that should remedy the issue:

• each Project would show only a few (5) jobsets by default. There would be a way to "pin" a jobset and thus allowing it to be at the top and shown. This allows jobs like master or release-16.03 to be visible on the front page
• Search will work instantly on the page you're currently on. For projects/jobsets it would filter on both lists by all fields. This should give you instant results of finding your project/jobset
• There will be a page showing only jobsets for a project, so you can link to that
• Projects page will have a button to switch "view" modes, so you'll be able to get only the jobsets/projects you starred or for example those that you own/maintain

Depending on your way of using Hydra these might help or not, but I'd like to discuss and think about the best solution once I understand more about the habits :)

[domenkozar]

Had a short hangout with @edolstra today and went through current infrastructure. Baby steps, next up is implementing routing for Single Page Application so I can move forward and implement other views.

[rbvermaa]

@domenkozar is it easy to test the UI with an existing hydra (or did you need a lot of extra API endpoints?) If it is easy, I can try and see how it turns out on our instance.

[domenkozar]

@rbvermaa currently all the state is hardcoded (the UI doesn't yet talk to the backend).

I plan to evolve the frontend first, so we can discuss usability and then with minimal change on the Elm side and a bit more on the Hydra side, I can convert current views to json views.

In other words: not yet, I will focus on the frontend first and then worry connecting data.

[rbvermaa]

@domenkozar OK, thanks!

[domenkozar]

@rbvermaa I've now implemented live search over jobsets/projects, you can test it at http://hydra-frontend.domenkozar.com/

Next up: url parsing, navigation (and start work on jobset view)

[domenkozar]

URL navigation is almost done: domenkozar/hydra-frontend#3

[ericsagnes]

I don't know how relevant this is, but a disadvantage of using elm for templates is that all the pages get empty if javascript is disabled, like for example when using a text based browser. (current hydra works quite nicely in text based browser)

[domenkozar]

@ericsagnes some text based browsers now support javascript, did you have a specific one in mind?

[ericsagnes]

some text based browsers now support javascript, did you have a specific one in mind?

http://hydra-frontend.domenkozar.com/ is empty when viewed in elinks, lynx or w3m.

[domenkozar]

@ericsagnes you're right, elinks doesn't open it despite the JavaScript support. While this is inconvenient to some, I don't see a way we can really fix this ourselves.

[domenkozar]

I've been working on this today, coded half of jobset page among other things (missing real data and configuration):

[domenkozar]

I've changed the UI again, see domenkozar/hydra-frontend#10 for more details.

[edolstra]

@domenkozar Can we close this?