search

usgo / online-ratings

AGA Online Ratings protocol and implementation
MIT License
23 stars 12 forks source link

Rewrite client in JS/TS and take advantage of client-side templating #29

Open artasparks opened 8 years ago

artasparks commented 8 years ago

I propose rewriting the client to rely on client-side templating rather than server-side templating. I have significant experience with AngularJS/AngularMaterial so that would be my preference. I could also see using TypeScript + Angular2.

One downside is it means the build is more complicated. However, moving the view-logic fully client-side makes for a far richer UI.

duckpunch commented 8 years ago

I'm not opposed to this generally, but I'm curious about what feature you're looking to get out of it.

artasparks commented 8 years ago

I think there are several wins:

So, arguments (2) and (3) really come from my experience using Angular. I previously spent lots of time migrating off of Soy (Closure Templates) onto AngularJS and the developer experience was much nicer.

duckpunch commented 8 years ago

Agreed on the cool features front. Not sure how that plays with timing.

Is there a deadline for OR?

artasparks commented 8 years ago

This isn't tied to a release and I don't see it as blocking for v1. I'll get to it if I have time. I've been thinking it's good to file issues for ideas to track them somewhere. As a side note, we should probably start creating milestones and tagging blocking issues to the relevant milestones.

duckpunch commented 8 years ago

Got it. In that case, sounds good!

On the topic of the ticket, how do you feel about doing this in a separate repo?

artasparks commented 8 years ago

On the topic of the ticket, how do you feel about doing this in a separate repo?

It might make sense long-term, but for now it's probably good to keep it in the same repo while we iterate on api. Also, I don't know how you'd do Protractor/webdriver style tests on Javascript in a separate repo, which could be a significant blocker.

duckpunch commented 8 years ago

Seems like iterating on the API and iterating on view code are two separate things.

In dev, it seems you could just have both up and running to do your testing. In CI, I think something akin to full stack testing is less important at this juncture.

I subscribe to the notion of the testing ice cream cone as an anti-pattern. Martin Fowler calls it a Test Pyramid.

duckpunch commented 8 years ago

The advantages you get are that you can rev, build, and package independently. Also, your integration points become pretty deliberate and explicit.

Anyway, not a point to get stuck on. I could see it working in the same repo for now.

artasparks commented 8 years ago

Those are good points and I especially take your point about being able to version and package independently. While OR still serves the JS/CSS resources, I'd make the case that these the JS should be included next to the job, but if they were served from a CDN or somewhere then it I agree that a separate repo would clearly be the way to go. Definitely a good idea to keep around.