Parsing HTML generated outside of Angular

It often happens that you have to work on some old project using jQuery. But in modern Web Development jQuery just doesn't cut it. So you write new features in Angular. But sometimes you have to modify existing code.

It's not a problem as long as HTML is static, but if it's generated on server side Rails+jQuery style, then Angular won't know anything about it when it arrives to a browser.

So we have make Angular parse this HTML. I remember a long time ago when I first encountered that problem I googled quite a lot but came up empty handed. So I had to find a way myself. Recently my colleagues stumbled on the same problem so I decided to share this little piece of code on the internets.

var $injector = angular.element(document).injector(); // first we get the injector our app uses
$injector.invoke(function($rootScope, $compile) { // you inject anything here in params
var element = angular.element('#selector'); // get the element we want to parse
// following hack isn't always neccessary, but I use to prevent double parsing if the same HTML is generated statically and dynamically
if (element.attr('class') && element.attr('class').indexOf("ng-scope")!=-1){
return;
}
var compiled = $compile(element)($rootScope); // finally, we compile the element against root scope
compiled.scope().$apply(); // ... and we tell Angular that we made changes outside of its 'world'
});
view raw angular_parse_html.js hosted with ❤ by GitHub

Well... That's pretty much it. You shouldn't try running your angular app again. It's going to create a separate application.

Also I want to share an interesting gotcha. If you inline your angular templates with 


<script type="text/ng-template" id="the-template" >
and they are in dynamically generated HTML you have parse this HTML. Strangely enough Angular doesn't use selectors to get this template. Rather it puts this template into template cache when encounters it during parsing.

Popular posts from this blog

HTTP server in Ruby 3 - Fibers & Ractors

Image
This is part #2. Head over to part #1 to learn about HTTP in Ruby. Motivation Historically Ruby's been lacking in the concurrency department. Ruby has "native" threads (prior to 1.9 there were only "green"), which means there can be multiple threads controlled by an OS, but only 1 thread can be executed at a time, this is managed via Global Interpreter Lock (GIL). However, native calls and I/O calls can be executed in parallel. During an I/O call, a thread gives up control and waits for a signal that the I/O has finished. This means I/O heavy applications can benefit from multiple threads. In this article we are going to explore different concurrency modes for our HTTP server: Single-threaded Multi-threaded Fibers Ractors Single-threaded Let's start simple and see how a single threaded HTTP server could look like ( full code ): def start socket = TCPServer.new(HOST, PORT) sock...
Read more

Migration locks for TypeORM

Image
Schema migrations is a must-have functionality for any DB framework. TypeORM provides decent utilities for dealing with migrations, however having a decade of experience in Ruby on Rails I got really spoiled and take some features for granted. One of these features is locking a database while a migration going on so 2 processes running concurrently don't step on each other's toes. This is also important when you run migrations in Kubernetes before launching your app. I was really surprised to find out that this basic feature is not supported , so decided to implement it on my own. Implementation // typeormMigrationUtils.ts import { Connection, createConnection } from 'typeorm' import config from '../ormconfig' import CRC32 from 'crc-32' const MIGRATOR_SALT = 2053462845 async function withAdvisoryLock( connection: Connection, callback: () => Promise<void> ): Promise<boolean> { // generate a unique lock...
Read more

Next.js: restrict pages to authenticated users

Image
Many websites have pages that need to be restricted to authenticated users, for example profile pages or dashboards. Next.js web framework comes with a lot of functionality built-in JS compilation, rendering code on server and caching. When it comes to most other aspecs, it's up to a programmer to build, including such needed functionality as restricting access to some pages only to authenticated users. In this article we are going to build just that: a function that augments a page object, that could be used like that: Here's the implementation in TypeScript: In order to make it work on server we are going to need one more utility function fetchWithCookies . When making HTTP request from inside a Web Browser, the browser automatically sends cookies with each requests and then stores new cookies if a response comes in with set-cookie header. On server-side we need to build this feature ourselves, because neither Next.js nor NodeJS make any a...
Read more