'JavaScript' blog posts

Angular, timezones and Datetimepickers

Recently we developed an angular application for one of our Multinational clients with the purpose of helping them to manage accommodation, transfers and flight times. This app had to deal not only with dates but also time and we looked into many different date and time pickers created specifically for angular in order to deal with that. We ended up selecting angular-bootstrap-datetimepicker as our choice.

At first hand everything went fine but during development the daylight saving period started here in Ireland and we noticed the dates being stored in the server started to differ of what we were picking in the app by one hour.

Javascript is somewhat confusing in how it parses dates, times and timezones, even some browsers handle some things in different ways and what was happening was when the datepicker was parsing the date into a javascript object it was also adding local time information e.g. 19/05/2017 11:18:00 +1 hour instead of 19/05/2017 10:18:00, which was actually the “numbers” that were picked in the datepicker. When this information was being sent to the backend, the server was parsing this date object without timezone information so the date being stored in the server was one hour wrong.

We didn’t want the application to be timezone aware, we wanted the users to pick a date on the datepicker and store that date made of the “numbers” that were picked. No smart conversions or anything like that.

The datepicker already provided support to moment.js (which basically the whole world recommends it if you are dealing with dates in javascript) so all what we had to do was to ensure when we are setting dates using the picker the selected date was in UTC timezone.

In order to achieve this behavior we had to add moment-timezone which gave us support to deal with timezones and then changing the code of angular-bootstrap-datetimepicker in the following way:

On the datetimepicker.js file, on the function setTime, one line after case ‘moment’ we added moment.tz.setDefault(“Etc/UTC”) in order to enforce the timezone to UTC every time we are setting a date.

By telling the datepicker to use moment we started to have issues with the angular filter for dates, which simply stop working, so we added another library called angular-moment to deal with that. So the code for the input that shows the date ended being this:

  

Further action: Doing some more testing we discovered that by using moment.utc() we don’t really need add moment-timezone or do the setDefault(“Etc/UTC”) thing. We have not given this a huge amount of testing, but the code would look like this:

 


Custom JavaScript parser vs Jison - Our experience

 

We recently announced QuickDBD, a simple product we made for drawing database diagrams by typing. If you take a look at the QuickDBD app you'll see it converts source code into a diagram. What we needed to make this work was obviously a parser.

After a bit of research on how to approach this problem, we knew that we would have to use either an existing parser generator or build a custom parser ourselves. After narrowing the choices down a bit, PEG.js and Jison emerged as the two most popular JavaScript parser generators at the moment. Out of these two, Jison seemed to have slightly bigger community - a bit more GitHub followers, more StackOverflow questions and a slightly better documentation. It seemed like a better bet so we decided to spend a bit of time playing with it and to try to make it parse the QuickDBD syntax.

We managed to make it parse the first version of our syntax we had a few months back pretty fast. But since the language we came up with for QuickDBD is closer to a data description language than what most people would consider a programming language, we started hitting bumps in the road pretty quickly as well. We soon ended up having to handle multiple edge cases we weren't able to with just Jison and what that meant was overriding Jison behaviour and injecting custom bits of JavaScript into it.

That kind of felt pretty messy so we talked a bit about it and made a decision to go with our own custom JavaScript parser for several reasons:

  • we would have complete control over how the parser works
  • everyone here is very well versed in JS
  • Jison was new to everyone and there is a bit of a learning curve in being able to do stuff with it efficiently
  • it felt as if we were fighting Jison to make it work something it wasn't supposed to more than it felt it was this great tool that was would empower us to do things better and faster
  • a couple of times it was pretty hard to get information on how to do something with Jison so we had to fall back to reading it's source code to figure things out
  • it didn't feel like the right tool for the job

We however did pick up some ideas from trying it out and I believe it made the custom parser we came up with that much better. We wrote a parser that's fairly small, fast and easy to read, expand and fix - which is ultimately what we needed.

I still think Jison is a great tool but it just wasn't a very good fit four for our needs. If you're considering using it, perhaps try it out on a smaller subset of features of your language first and see how you like it before committing to it. You can always go back to writing something custom after you tried it out.

I also recommend you read this very good parser generators vs custom parsers SO thread with pros and cons for both sides.

Hope this helped!


Should you use Angular2 in production?

Recently we had a small debate about Angular2 and what the benefits and pitfalls of using it for a project right now would be. In the end Fabrizio and I came up with a short list of pros and cons.

Pros

  • Typescript will force developers to write better code.
  • Angular2 should be faster than the Angular1.
  • It is best not to invest in a framework if it is to be shortly discontinued.
  • You will be one of the Angular2 pioneers.
  • The development process will be very strict and it will require a good knowledge of the project.
  • Localization of application will be easier with the implementation of the shadowDom.
  • Debugging templates will be easier because they will raise runtime exceptions.
  • The code needs to be built before deployment. This will slow down the process but will spot code errors and typos.
  • Gaps between browsers implementations of new standards will be handled by specific libraries (Angular2 will emulate the shadowDom).

Cons

  • It is in an Alpha version. It means that the inner structure could (and it will) be subject of big breaking changes.
  • The API is not stable yet (breaking changes will be introduced).
  • Not all features are implemented yet (you will have to reinvent the missing parts and then once they get officially implemented, your custom workarounds will be obsolete and probably not as optimized and not as good as Angular2).
  • Not enough documentation. Also not enough code examples on the web, so much work will be pioneering.
  • Ecosystem is not there yet (not all libraries and tools are ported yet). For example: there is an alpha of Bootstrap; Foundation isn’t there yet; the router is not ready yet. The lack of availability of convenient libraries may mean more development.
  • Both versions will remain on the market and both of them will be actively developed.
  • The team is still thinking about "how to do things for Angular2".

So that's what we came up with. Of course there is no ultimate answer and surely Angular2 will be a good tool once it's ready. But before that happens, we think it's probably best not to use it for serious projects that need to go into production.

Speaking of framework readiness here is an appropriate comic from Commitstrip that hits the spot.

undefined


Some things I like this week

Here are some things I like this week. Broad category here: Designs, Art, Libraries. I know I'm just linking here, but a lot of interesting things came past my inbox/reader this week.

Cuban Council Portfolio. Found this site today. Very unique design and typography. The blog has a nice collection of photos and design related things. Their portfolio is also very impressive and presented in an unusual yet very usable fashion. They designed the Facebook logo!! Very Cool.

Dublin Contemporary 2011. I highly recommend visiting one of the exhibitions for this. It ends this weekend, so get out quick and snap up some alternative inspiration.

The Role Of Design In The Kingdom Of Content. It's true now more than ever - Content is King. This article goes a great job explaining why great content needs to be supported by great design. Let your designs support your content, rather than dilute it.

Regardless of what your content actually says, the design around it controls what the users see first and how their eyes move across the sections of the page.

Notificon. A gmail-like favicon notfication library, and all done with JavaScript too. Very Nice.

And finally, because it seems the world cannot have enough lightwieght single use JavaScript libraries: money.js

Designed to work seamlessly with data from the Open Source Exchange Rates API project - but can be set up to use any data source and base currency in just a few lines. And it works as a NodeJS/CJS and RequireJS/AMD module, too. Yay!


  • 1