Reading Time: 2 minutes
VS Code + Emmet
If you’ve spent any amount of time programming, you will learn quickly to enjoy a particular editor or IDE. The great part of Visual Studio Code is that you can extend it in ways that you’d never believe sometimes. Emmet is just one of those ways.
Emmet might be the coolest extension I’ve seen. The ability to expand a sequence of characters into actual HTML or CSS is incredibly nice – especially once you get into the habit of using it.
- HTML5 Boilerplate
- Tag Manipulation
- Custom Tags
- Cheat Sheet
Take this for example:
Just some boilerplate HTML5 setup syntax.
Believe it or not, you can very quickly create this with 6 characters and a ‘tab’ – ‘html:5’, tab
Check it out:
The power of Emmet really comes into play when you’re looking to create an expansion of some slightly more complex html. For instance, what could be a common scenario is to have a list with many list items in it. Doing this again requires very little work:
It even works for custom HTML tags, which is especially nice when working with a front end framework like Angular, React or Vue:
This extension is just extremely flexible.
Another area that you can utilize Emmet is with CSS files too.
Just incredible how well it speeds up boilerplate syntax.
There are so many shortcut sequences that it’s quite overwhelming to say the least, but to get it down you will be crazy efficient. Check out the entire Emmet cheat sheet here: https://docs.emmet.io/cheat-sheet/
One of the most important parts of development unfortunately (or fortunately?) requires us to create a lot of the same exact code/syntax with very similar constructs all the time. Being able to be more efficient when working with that boilerplate set will allow you to spend more time working on solutions – a win for everyone. If you get a chance, I highly recommend seriously using Emmet. You won’t regret it.
Reading Time: 2 minutes
My list of how not to completely screw yourself over on a large-scale AngularJS project – The biggest project I’ve done has gone from Angular 1.0.x to 1.4.x. These are what my findings were:
- Setup the style guidelines right from the get-go. Seriously, this simple starting point will in the end give you at least the advantages of keeping code clear. John Papa has a community driven one on github that’s excellent.
- Get comfortable with directives. Review the way that some of the more popular ones are setup and created. DRY is your friend in any application, and doubly so in a large one.
- Be sure that everyone that is going to be working on the design end of it (CSS, LESS, SASS, etc.) are capable of the work. The more complex the CSS of the site, the more potential to royally screw up the UI there will be.
- Setup your Linters from the get go. JSCS and ESLINT are my preference. I also highly suggest Uncss and Stylestats for the UI CSS work that’s being done.
- Consider a LESS or SASS Library to standardize some basic mixins to use throughout the UI.
- If possible, get at least Directive unit tests working properly. It’ll save you many debugging headaches.
- Be sure to well document an actual snippet for your directives for use in a top of file comment block. Nothing more annoying than needing to use a random directive that requires you to read all the code to know how to use it properly.
- Most browsers work properly most of the time, until you open things in IE.
- Get auto-deploy setup to dev servers. Makes having the latest builds available to QA a lot easier when somewhat centrally managed.
- If you use $broadcast just throw your computer out of the window.
- Don’t roll your own translation directive. Use angular-translate or another community option.
- Get used to arcane console.log errors.
- If you encounter your app having infinite digest cycle errors, you’ll realize very quickly that they’re not easy to diagnose. I highly suggest reading my post on finding them in a large app and what worked for me.
I may add more to this list in the future – but have fun and make cool stuff!
Reading Time: 1 minute
I’ve been doing a LOT of CSS with my projects as of late, mainly with SASS and LESS, but that isn’t related to this issue.
In creating a popover textarea entry directive, I got all of the CSS in place and then noticed that for whatever reason the textarea wasn’t showing any text that I entered into it.
It would appear if I toggled any of the CSS properties in the Chrome Dev Tools, however, my issue remained. If I removed the position absolute, it would work. I was clueless as to what would resolve this, but at least I could see changes when modifying stuff.
And then I noticed, I had wrapped the outermost tags for the directive in <span> tags like this:
When I set the <span> tags to <div> tags, voila, everything worked as I had intended. After looking into it further, I realized that the span tags only should be used for inline-level components, and I was using <div> elements inside of the <span> tags, which are block-level elements. As a result, the <span> tag breaks the html in that it doesn’t allow block-level children.
So if you run into an issue like this, check the surrounding tags. Here’s a W3C detail on the span tag for those interested in further technicals: http://www.w3.org/TR/html51/semantics.html#the-span-element