Just downloaded Dexie.js-3.2.1.zip. Unlike a previous version I was using, this contains a dist/modern directory. How do files in this directory differ from those in the dist directory?
They are ES2018 compliant and not ES5. The modern subfolder contains one minified and one non-minified version of dexie in the newer ecmascript module format (.mjs) and also contains "modern" syntax that cannot be read by old browsers, such as arrow functions. The latter is how they differ from dexie.mjs directly under dist, which has legacy JS syntax except for the module format. Those under modern has both modern module format and JS syntax.
If you do not care about Internet Explorer compability, you can choose to use the modern versions but they need to be included differently:
<script type="module">
import Dexie from 'path-to-download/dist/modern/dexie.min.mjs';
const db = new Dexie('myDB');
...
</script>
You can also use import maps:
<script type="importmap">
{
"imports": {
"dexie": "path-to-download/dist/modern/dexie.min.mjs"
}
}
</script>
<script type="module">
import Dexie from 'dexie';
const db = new Dexie('myDB');
...
</script>
The modern version of dexie is also refered from its package.json so that bundlers such as webpack will find it and get a non-transpiled version of it.
The benefit of using modern version is smaller size and theoretically faster execution and optimized memory consumption. But I do not think these things matter so much. You would never notice a difference in performance between the legacy and the modern version.
Related
Any soild reason I should prefer the sass partials over normal sass files (w/o leading underscore in the filename)?
I am not a full-time frontend developer and for now I use sass for simple organizing of my css - split styles into different files(modules/components), variables, functions, in-place calculations, mixins - I think that's all I do.
In general I create a single main sass files that combines all the files together like that:
// main.scss
#import 'vars'
#import 'funcs'
#import 'layout'
#import 'component/modal'
// etc.
And recently I noticed there is such thing as partials.
From the documentation I understand partials are independent files that are not exists on their own and are always a part of some other bigger modules.
By this logic it looks like vars.scss, funcs.scss are good candidates to be partials.
And what I can't understand is why _vars.scss is better than vars.scss.
The both variants will work well from the point of view of code splitting.
Possible reason is Compilation - the docs page says partials will not be compiled into separate css file. I can't agree that's a feature since it's fully under my control and depends only on how I configure the building tools I use. And anyway such sass internal things like variables/functions/mixins will never be translated directly to css - they only exist in the source code.
So I would like to understand maybe it's just a convention for visual separation internal files from others? You know there is a similar old practice of separation private/public members/variables in programming. Or maybe I just miss something?
Please advise what I can do with partials what I cannot do with normal files, are there any advantages of first ones?
Hi I am trying to organise my sass files into separate chunks on a project using GULP. However when I import my mixins and variables in separate files:
File:variables.scss
//first import variables that might be used throughout all the other files
#import "common/_variables.scss";
File:mixins.scss
Mixins
#import "common/_mixins.scss";
Then try to access those mixins from other files for example
File:buttons.scss
#import "common/_buttons.scss";
I get the following errors when running gulp sass:
throw er; // Unhandled 'error' event
no mixin named 'foo'
or
undefined variable 'foo'
In spite of the mixins/variable being defined in the variable.scss and mixins.scss files. So gulp interrupts the task half way though and the stylesheet is not created.
Is there a rule in SASS that means the variables and mixins must all be imported in the same files using them? If this is the case, it is a problem as I have a lot of files I would like to keep separate and not have to keep importing both mixins and variables inside them.
The short answer is you dont have to import them into everyfile that might include them. However there does need to be a relationship somewhere, and how you do this depends on whether or not you are looking to build one single final CSS file - or a series of individual files.
If you want the former, you could consider having a master import file that does little more than import all the appropriate *.scss files, and have this be the main SASS file your gulp build script looks to compile.
You'll need to take care to import files in the correct order - so no importing a file that uses a mixin before the file that defines the mixin has been imported it's self.
So for example - personally I work with a main.scss file that is structured as
#import "common/_variables.scss";
#import "common/_mixins.scss";
// Now import the files that might use these vars/mixins
#import "common/_buttons.scss";
which is built via gulp to create css/main.css.
Should you want a series of CSS files - i.e. buttons.css, type.css, layout.css etc - then you would need to have the appropriate variables and mixin #import declarations in each file that calls them
I found the best solution for me with pre-concating SASS files with GULP.
Like in this example for STYLUS
gulp.src(config.projects.css.source)
.pipe(sourcemaps.init())
.pipe(mktimecss(__dirname+'/web'))
.pipe(concat('styles'))
.pipe(stylus({
'include css': true,
use: [nib()],
// compress: true,
linenos: false
}))
...... and so on .......
It is most definitely possible to have your mixins and variables in different files. In fact, I'd recommend any mixins/variables that you find yourself reusing, you should take a more global approach with them instead of importing them into individual files.
One of the best ways I've seen for organizing a directory of Sass files is called The 7-1 Pattern and makes the entire structure of styling so much easier to understand and build upon.
The most applicable piece of this organizational strategy to your question would be creating a main.scss file that imports every one of the files you plan on using. Make sure you're careful about the order that you import, though. You can't import a file that uses mixins or variables from a file imported after it.
I'm trying to use two libraries:
D3 (a Javascript graphics library)
NVD3 (a graph-specific D3 extension)
I'm also trying to use the Require Optimizer, and that's where things get rough. D3 is AMD-compliant, so if it detects that you're using Require it will define a module and NOT export a global d3 variable. NVD3 has no AMD support, but Require has "shims" for that case.
However, if I "shim" NVD3 and give that shim a dependency of D3, it doesn't work, because NVD3 expects there to be a global d3 variable, which D3 won't make in a Require environment. So, to get around this issue I made a new module (d3Shim), which simply requires D3, then registers it as a global variable:
define(['d3'], function(d3) {
return window.d3 = d3;
});
I made NVD3 depend on d3Shim, and then everything worked ... in normal Require-land. When I tried to use the require-optimizer to merge everything together in a single file I found NVD3 started breaking again, because of a lack of a d3 variable.
It turns out the optimizer does this for shims:
*shimmed code here*
define(*shim path*, [], function(){});
So, it doesn't matter what dependencies I have, the NVD3 code will run before the d3shim module can do its magic.
My question is, is there any way I can use these two libraries with the Require Optimizer, without having to alter either file? If necessary I can always edit NVD3's code to make it an AMD module, but for obvious reasons it's bad practice to edit 3rd party libraries, so I'd prefer a non-editing solution.
I am trying to add some support for D programming language to my vim config. For autocompletion I need to detect packages that are included. This is not exactly hard to do in simple case:
import std.stdio;
import std.conv;
My config:
set include=^\\s*import
set includeexpr=substitute(v:fname,'\\.','/','g')
Works great.
However, imports can have more complicated format, for example:
package import std.container, std.stdio = io, std.conv;
I was not able to find a simple way to parse this with include and includeexpr.
Also there is a second problem: import can have different access modifiers, like public and private. VIM scans included files recursively, import statements from included files are parsed too. But I need to distinguish between the file I am working with now and files which are scanned automatically: in current file all imports should be detected, but in other files only public import statements should add more files to the search.
Thanks for help.
Update
It's a shame if this can not be done without full parsers. Essentially, I only need two things:
ability to return an array from includeexpr instead of one file name
ability to distinguish between includes in current and other files
I think only way to do it reliably is to use complete parser and semantic analyzer. D Completion Daemon (https://github.com/Hackerpilot/DCD/tree/master/editors/vim ) has vim plugin and is not very resource-hungry.
Vim's include mechanism and 'includeexpr' are heavily influenced by the C programming language and only work for single files. You cannot return a list of filenames, so it won't be possible to support D's complex include mechanism with Vim. Use an IDE that is fully tailored to support the programming language, not a general-purpose text editor.
The reference page (use "toggle all") for Processing.js says the import command remains unimplemented. It references a page for the Java Processing language that describes a usage pattern like this: import processing.opengl.*;
I see at Github that some work on the import command was committed to the root in May. Does anyone know how this syntax works in a JavaScript environment? It's not clear what the path to the library file and its assets would be. Does this depend on the use of an environment variable similar to PYTHONPATH, or is there a directory naming convention?
Finally, would you care to discuss the relative merits of the import command (assuming it now works) versus the approach described here, and discussed briefly here on StackOverflow.
I was looking for a similar solution. Perusing the processing.js base code, I noticed that you can simply list multiple files in your datasrc declaration if you separate the file names with spaces. That kind of does what I want, although the result is multiple ajax calls to load the separate scripts.
<canvas id="test" datasrc="resources/pjs/Spot.class.pjs resources/pjs/cursor.pjs"></canvas>
I think a cleaner solution, given the current state of the processing.js code (as of July 2010) would be to simply build a server-side code concatenator a-la minify:
http://groups.google.com/group/minify