Is it possible to access a SASS variable in an Angular controller?
At the moment I'm creating a bar chart and I have the colors in an array e.g.
var barColors = ['#fff', '#e32dsa'];
Would be nice if there's a way so i can ensure code is easier to maintain.
Thanks.
This can be done with sass-extract which also includes native support for sass maps, arrays, #imports and so on.
Either use it on the server and include the JSON result in the response to the client, or use sass-extract-loader with webpack to simply require the sass file in your controller.
in your style.scss file
$barColors: #fff #e32dsa;
in your controller.js
const style = require('sass-extract-loader!./path/to/styles.scss');
const $barColors = style.global.$barColors.value;
console.log($barColors[0].value.hex)); // '#ffffff'
console.log($barColors[1].value.hex)); // '#e32dsa'
You could try moving to webpack(a module loader that also does a bunch of other fancy stuff like requiring in sass) and pulling in this loader https://github.com/buildo/sass-variables-loader
Related
My reactjs app consists of a bunch of typescript files with a clean separation of GUI and model. The webworker needs most of model files, so maybe half of all files. I could imagine loading the webworker from exactly the same URL as the app as the model does reference neither the GUI nor React nor other unavailable stuff (At least, it shouldn't, and if so, it'd easy to clean it up).
There seem to be some problems:
finding the correct javascript files
injecting proper start up code into them
and probably others I haven't thought about yet.
The communication to the webworker is not a problem as all I need is a single async call passing and receiving some simple data.
There may be more issues like e.g., https://github.com/microsoft/TypeScript/issues/20595.
Before I learnt what I really need, I tried e.g., ttps://www.npmjs.com/package/#koale/useworker, which is nice, but seems to be able to deal with plain javascript dependencies only.
Finding the correct javascript files
What I can see in index.html is
<script src="/myapp/static/js/bundle.js"></script>
<script src="/myapp/static/js/0.chunk.js"></script>
<script src="/myapp/static/js/main.chunk.js"></script>
<script src="/myapp/main.4e45e2b4b645351b7733.hot-update.js"></script>
I guess, I could live without hot updates, however the names of the other three files change in production to something like "/myapp/static/js/2.28cf00cf.chunk.js".
Injecting proper start up code into them
When the worker loads, it executes some webpack code generated code which most probably crashes it. I'd need to avoid it somehow.
The questions
Is this doable at all?
Does it make sense or is there a better approach?
For a seamless integration of worker code with main-thread code, I recommend using comlink-loader. For example, if you have a main.ts file and a thingy.worker.ts file, you could seamlessly load it as a worker by using TS imports:
// main.ts
import { getThing } from "./thingy.worker.ts"; // make sure the file name ends with .worker.ts
async function test() {
console.log(`the thingy is: ${await getThing()}`);
}
// thingy.worker.ts
export async function getThing() {
return 3;
}
You'll need to add it to your webpack config like this:
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /\.worker\.(js|ts)$/i,
use: [{
loader: 'comlink-loader',
options: {
singleton: true
}
}]
}
]
}
}
The best part is that your editor's intellisense will work across modules and type safety will not be compromised. More documentation is available here.
You need to compile a separate js file for your WebWorker. There is a React lib called react-webworker that makes this easier for you. It in turn uses WebPack’s worker-plugin.
I understand that requirejs and browserify can load my files dependent on its current context, and that it is amazing. I would really prefer to use the #section sections syntax that the razor engine uses. Was just wondering if there is a way to implement this into a typescript / angularjs application.
for example
index.html
#renderSection scripts;
// which could turn into something like
<script data-render="scripts"></scripts>
// the app.run() could declare all the scripts that will be needed on every
// page view
view.html
<script ng-section-repeat="injected in injection"></script>
// the ng-section-repeat is basically taking all the items in the
// typescript constructor and then finding out which ones are needed for
// that view.
I like the idea injecting application file dependencies in the view , without a configuration file and all the added extras that comes with the loaders.
I just want to easily define what files are needed in the actual view and get them loaded, with angular's dependency injection handling the dependency itself.
If you are handling all your dependencies with $inject then , as far as i can tell, dependency is technically already setup in the controllers, all one would need, is to load this as it is called. Which could even eliminate the need for the #section scripts completely
Update:
What i have done to sort of replicate the module loaders is to just use gulp-concat and define the file order in my gulp.config.js and then pass it to the gulp-src before running $.concat .this allows me to have the files in the gulp steam , in dependent order . They are however loaded on the first load. With gulp-uglify the files are tiny ( its now at 566Kb with 16 external libraries loading in 69ms . To put that into perspective it takes 209ms to load one google font ).
I dont know maybe i am not understanding browserify correctly but i honestly struggle to see the need for it, its seems extremely convoluted for something so simple
It is possible using external modules and an injector to do what you asked for:
I just want to easily define what files are needed in the actual view
import {UserFactory} from 'models/userFactory';
import {UserValidator} from 'models/userValidator';
import {Inject} from 'angular2/di';
and get them loaded, with angular's dependency injection handling the dependency itself.
Note: My example uses angular 2.x because I less familiar with angular 1.x and I'm sure you can do something really similar...
class SomeComponent {
userName: string;
userRating: number;
rating: number;
constructor(
#Inject(UserFactory) UserFactory
#Inject(UserValidator) UserValidator
)
{
this.UserFactory = UserFactory;
this.UserValidator = UserValidator;
}
}
Then you can use Browserify to create a bundle.js file that can be executed in a web browser.
I am trying to have external modules change my $translateProvider.translation on the main module. see this as a "tranlation plugin" for my app.
it seems like changing translations from the $translate service is not possible.
mymodule.service('MyService', function ($translateProvider) {
var lib = function () {
//EDITED FOR BREVITY
this._registerTranslations = function (ctrl) {
if (!ctrl.i18n) return;
for (var name in ctrl.i18n) {
/////////////////////////////
// THIS IS THE PLACE, OBVIOUSLY PROVIDER IS NOT AVAILABLE!!!!
$translateProvider.translations(name, ctrl.i18n[name]);
//////////////////////////////
}
};
//EDITED FOR BREVITY
};
return new lib();
});
anyone with a bright idea?
So, to answer your question: there's no way to extend existing translations during runtime with $translate service without using asynchronous loading. I wonder why you want to do that anyway, because adding translations in such a way means that they are already there (otherwise you would obviously use asynchronous loading).
Have a look at the Asynchronous loading page. You can create a factory that will load a translation from wherever you want.
I created an Angular constant to hold new translations. If I want to add a new translation, I add it to the constant. Then in my custom loader, I first check the constant to see if the translation exists (either a new one, or an updated one). If so, I load it from the constant. If not, I load it from a .json file (or wherever you load your initial translations from). Use $translate.refresh() to force translations to be reloaded and reevaluated.
Demo here
The demo is pretty simple. You would need to do a little more work if you wanted to just change a subset of the translations, but you get the general idea.
From the AngularJS docs (https://docs.angularjs.org/guide/providers):
You should use the Provider recipe only when you want to expose an API for application-wide configuration that must be made before the application starts. This is usually interesting only for reusable services whose behavior might need to vary slightly between applications.
Providers are to be used with the application's .config function. $translateProvider for configuration, $translate for other services and controllers.
I try to use two dependencies:
"snap.svg": "~0.2.0", # snapsvg.io
"angular-snap": "~1.4.1", # jtrussell.github.io/angular-snap.js/
How I guess, it seems angular-snap uses a global Snap object as snap.svg and overrides the Snap object of Snap.svg.
In this order the Snap.svg functionalty goes away. If I revert the order of import, some Snap.js functionalty is missed.
Watch this plunkr http://plnkr.co/edit/rE4pNDqQnBh2e5wtqGUO?p=preview and swap the includes.
How can I use both libs?
Thx ahead!
I think your best bet is going to be using a module loader like RequireJS to pull both Snap.js and Snap.svg into you application in a controlled way, it looks like both support AMD module loaders.
Unfortunately this will mean you won't be able to rely on the snap-content directive from Angular Snap anymore. You'll need to create a new Snap.js snapper instance yourself and make use of snapRemote#register.
Here's some pseudo code:
require(['jakiestfu/Snap.js/snap'], function(SnapJS) {
snapRemote.register(new SnapJS(snapOptions));
});
require(['adobe-webplatform/Snap.svg/snap.svg'], function(SnapSVG) {
// Do stuff with SnapSVG...
});
Also, you'll want to assign a "snap-content" class name to the element you initialize your snapper with (this is also usually handled by the snap-content directive).
Edit:
I'm not recommending this approach but it should work as well if you don't mind some hacks:
In your head:
<script src="//cdn.jsdelivr.net/snap.svg/0.2.0/snap.svg.js" type="text/javascript"</script>
<script>
// Save Snap.svg before it gets clobbered!
window.SnapSVG = Snap;
</script>
<script src="snap.js" type="text/javascript" charset="utf-8"></script>
After that you could go on using the svg Snap as SnapSVG or whatever you want to call it. The module loader approach is arguably better in almost any way you want to look at it... unless you need to ship tomorrow :).
Edit 2:
I just released v1.5.0 of Angular Snap which makes the Snap.js constructor an injected dependency rather than something we just look for on the window. You could now provide your own constructor, maybe saving it before it gets clobbered:
myApp.config(function(SnapConstructorProvider) {
SnapConstructorProvider.use(window.Snap);
});
Using this you'll still be able to take advantage of the snap-content directive even if you pull in the Snap.js script with a module loader.
I'm currently migrating from custom framework to Angular. Since we've got legacy, all front-end resources like stylescheets, images and scripts should be located on a subdomain, and all urls should be absolute. I've got a bunch of css files with a parameter specifying our static domain. I'm looking for a native Angular approach to using parameters in css, so I'll be able to write smth like:
.body {background: "{{domain}}/img/bg.png";}
Currently in our framework styles are loaded with, say, $http.get(), then processed with .replace and then appended to DOM.
Any ideas?
Thank you.
Try the $interpolate service. Inject it in a method, then use like this:
var fn = $interpolate(cssText);
var processedCssText = fn(scope); // scope is whatever obj that contains `domain` and other properties that might be used inside cssText
You can even configure the opening & closing symbols, if needed. See the documentation for $interpolate for more information.
You want LESS.
http://lesscss.org
It's the "dynamic stylesheet language".