The past couple weeks have been a whirlwind for me (more for personal rather than coding reasons), but I finally had a chance to sit down and do some real front end stuff today that I wanted to share with you. Before I get to that though, you might be wondering what I’ve been up to. Here are the highlights:
- Built a weather app in React Native and even added some simple tests to it (started adding redux to manage state, but got side-tracked with work stuff). I can see why people love React Native for prototyping mobile apps!
- Implemented a cluster of RethinkDB instances to handle web sessions (we just kind of had the instances laying around so may as well use ’em).
- Created a public version of some data visualizations we provide to our customers so that prospective customers can interact with the real thing. D3 and React for the win!
- Began working on a Python package of the algorithms in the tome “Data Structures and Algorithmic Thinking in Python” by Narasimha Karumanchi. My Hackbright mentee is a collaborator.
So there you go.
Today, I updated the styling on a web widget. Tweaked it really. Super simple, but it was fun and as often happens I learned something. Namely, that there is a quick and easy way to truncate, with or without an ellipsis, the text node of an HTML element.
First, here’s an example. I might update this soon with an animation (ok, I did), but the key is that there is a single style class that contains the three CSS rules that will allow you to handle any length of text. That was my use case; people were changing the widget’s title, as they are wont to do, but neglecting or forgetting the maximum character length allowed. If you went beyond that length bad stuff would happen. Like your title might overlap other text.
So the first somewhat obvious thing to do is to add an ‘overflow’ rule and set it to ‘hidden’. Basically saying if some child elements go beyond the boundary of the parent element then hide that part of it which extends beyond. Ok, that’s just my observation of what happens.
That’s great, but turns out my text node would just word wrap and my parent element would get taller and theres my text overlapping again. Ok, well the solution there is obvious: set the height! This truncates the text at the width of our containing element. If you want that width to be something different then you need to set the width as well.
But how can I better predict where the truncation will occur if automatic word wrap is still wrapping the text to a now hidden new line? There’s a CSS rule for that: ‘white-space: nowrap’. Now you know whatever text is there will be truncated on exactly at that width.
Finally, wouldn’t it be nice if instead of just lopping off the text at the specified width, which in my use case could vary from widget to widget, wouldn’t it be nice to have some indicator to our dear internet users that says, respectfully, we’ve truncated this for your convenience and enjoyment because seriously, TL;DR dude? Well, your old friend from
English Lit. click-bait headlines, the ellipsis, is available in CSS too! Try ‘text-overflow:ellipsis’.
Recap: so to achieve the above effect we implemented three CSS rules: overflow, white-space, and text-overflow. We also set the CSS rules height and width. If you don’t believe me or my example then check it out on Stack Overflow.
Another interesting thing I ran into when updating the widget was that testing it locally from files on my machine, as opposed to from files served over the internet, I was at first unable to render it because postMessage would fail. This is because postMessage checks the origin of the parent window (from the embedded iFrame which I use for the widget). Luckily, I had a nice reminder of the proper way to handle this in a secure environment from this post on Stack Overflow. The key here is that it was ok for me to update my expected domain to the wild card “*” string, as suggested by the Stack Overflow answer, only because there was no chance of the wild card getting into production code. Keep your code secure!