I'm fresh Dart appretience and I'm trying the 'one-hour-codelab' tutorial. I'm using IntellijIDEA 14 and its Dart plugin.
When I build 'Debug', everything works OK in Dartium.
When I build 'Release', Dart code gets translated into Javascript, but HTML code is still referencing the Dart source file.
I assume there is some solution for this, do you know it?
Thanks
Rene
The source is meant to still point at the .dart files, since if the browser has a Dart VM in it, you want to use that rather than the generated JS. It's the job of the dart.js script (which is part of the browser package) to figure out if the browser you are running on has a Dart VM or not, and if not, to substitute in the appropriate JS scripts.
For example, the source of your index.html file might look like this:
<html><body>
<script type="application/dart" src="main.dart"></script>
<script src="packages/browser/dart.js"></script>
</body></html>
In browser with the Dart VM (like Dartium) the dev tools will show those same script tags. However, in vanilla Chrome or another browser, the HTML you see in the dev tools will look like this:
<html><body>
<script type="application/dart" src="http://localhost:8080/main.js">/script>
<script src="packages/browser/dart.js"></script>
</body></html>
This is because the dart.js script has replaced the main.dart script with the corresponding JS file.
If you aren't seeing this translation happen, make sure that you are including the dart.js script in your index.html file, and that you are using the browser package by adding it to the dependencies of you pubspec.yaml file:
dependencies:
browser: any
It's worth noting that the --mode=release option for the pub build command doesn't include the .dart files in its output, but other modes will (https://www.dartlang.org/tools/pub/cmd/pub-build.html). I suppose that since no browsers in the wild currently have a Dart VM in them, that pub build assumes you only want to release JS files. I suspect this might change if/when vanilla Chrome gets the Dart VM added in. In the meantime, after you build your project, if you want it to also work in Dartium, you'll need to add in the .dart files to the build output. If you wanted to get extra fancy, you could minify your Dart first by using dart2js with the --output-type=dart flag set (https://www.dartlang.org/tools/dart2js/#options).
Related
I'm experimenting with Vite, VueJS 3 and vite-plugin-singlefile for an app which is bundled to a single HTML file, and then served inside a sandboxed iframe through a parent site I don't have much control to change.
Specifically, the iframe runs sandboxed with <iframe src="someotherorigin/page.html" sandbox="allow-scripts allow-same-origin allow-forms">. My built HTML page references some external scripts via CDN (e.g. Bootstrap, etc), but the actual app code itself is inlined.
The app works fine with Vite's dev server and build+serve option. It's also fine when I preview in other tools... But in the target environment it seems like the main entrypoint script simply doesn't run. Nothing renders but also no error messages in console. I do get a couple of warnings about malformed CSP, but that's all:
Content Security Policy: Interpreting none as a hostname, not a keyword. If you intended this to be a keyword, use 'none' (wrapped in single quotes).
Content Security Policy: Interpreting https://none as a hostname, not a keyword. If you intended this to be a keyword, use 'none' (wrapped in single quotes).
This question got me curious so I tried manually editing the built index.html to change the inlined <script type="module">...</script> to <script>...</script> - And it works fine!
...But:
I can't make that change in the source index.html (Vite just ignores & refuses to bundle the TypeScript /src/main.ts source unless "module" is set)
I don't think there's an easy way to automate changing it in the build pipeline either (seems like it'd be messing around with custom Vite plugins)
I don't really understand what's wrong in the first place - why would type="module" cause the iframe not to run this Vue-generated script? Is there some other more proper fix?
I'd like to compile ".vue" components (with contains html/js/css) into JS, but in browser side, without browserify/vuify/webpack or others ...
In a better world, i'd like to include my ".vue" component into my html app, like that, withoud need of compile things, server side:
<script type="vuejs/component" src="myComp.vue"></script>
It should be possible ?! no ?
(And I can't imagine that no one got this idea, or have done it already)
In fact, it's possible with http-vue-loader :
https://github.com/FranckFreiburger/http-vue-loader
It doesn't make sense to compile in the browser when it's so much more efficient to just pre-compile your component locally instead of relying on a visitor's client to do it.
In fact, the answer above regarding vue-http-loader says it's only for use in development and links to this article: https://vuejs.org/2015/10/28/why-no-template-url/
With that said, I created a vue-cli template that lets you pre-compile .vue files into a single .js files you can use in the browser. The single JS file contains the template, script, and styles. It uses webpack, but it's super easy to run and watches your files as you edit them.
$ vue init RonnieSan/vue-browser-sfc my-project
Repo at: https://github.com/RonnieSan/vue-browser-sfc
Instructions are in the README.
I'm using sails(http://sailsjs.com) to develop a little platform. Everything goes smoothly following the documentation. But being new to this javascript frameworks world and npm etc etc, i've been having a trouble including other node_modules and use them in the .ejs views...
I understand not all modules are to be included in the views but how can I manage to include some?
Trying to use https://www.npmjs.com/package/vue-slider-component
Thank you in advance and sorry if this error is just plain out stupid.
Your confusion is understandable. The issue is that, until relatively recently, things installed in node_modules were solely for use in the back end code; that is, your Sails.js controller actions, models, etc. After all, the node_modules folder has the word "Node" right in it, and it was created for use with NPM (the Node Package Manager) to help organize Node (i.e. server-side JavaScript) files!
While many front-end plugins were (and still are) published on Bower, newer frameworks like Angular 2 and Vue often publish their plugins to NPM because it reduces the number of moving parts for your app. The problem is, if you try to require('vue-slider-component') in your server-rendered .ejs view, the server (i.e. Sails.js) will try and load and run that code before it renders the view, where what you really want is for that plugin to run in the browser.
The long-term solution is to use something like Browserify or Webpack to compile all of your front-end JavaScript files into a "bundle". So for example if you have a file like assets/js/my-vue-app.js that includes the line:
import vueSlider from 'vue-slider-component/src/vue2-slider.vue'
then Browserify will see that line, load up that vue2-slider.vue file, add it to the top of the my-vue-app.js file, perform some other magic, combine it with your other front-end .js files and output a file like browserified.js which you would then include via <script src="/path/to/browserified.js"> in your HTML.
Since new Sails apps use Grunt to organize and inject those <script> tags into your views for you, it can be kinda confusing as to how you would get something like Browserify or Webpack to work with Sails. For Sails 1.0, there's a seed project for using Webpack instead of Grunt. For Sails v0.12.x, you'll have to Google around to find some examples of using Broswerify or Webpack with Sails.
A short-term solution, and probably not as maintainable in the long run, is to save the contents of the minified vue-js-slider component into your assets folder (e.g. as assets/js/vue-slider-component.js), add it to your HTML with <script src="/js/vue-slider-component.js"> and access it in your code as window['vue-slider-component'].
I want to server a Dart application on an Apache server. I added the line
application/dart dart
to the mime.type file in the Apache configuration. Still I get the error
Resource interpreted as Script but transferred with MIME type text/plain: "http://localhost/~d022051/mastermind/web/mm-game.dart".
Another issue is the link to the packages directory. I do not want to have symlinks in the documents directory of the server. Is there a smart way to copy the required packages in the correct version?
This message has nothing to do with Apache.
It's a while that I worked with Apache, but as far as I know you don't need specific settings to serve a Dart client app using Apache. They are just like any other static HTML, CSS, JavaScript, or image files.
You get this message because the entry page (index.html) contains a script tag for a Dart script. After you run pub build there are no Dart scripts (yet) in the build output (this will change when Chrome supports Dart and pub build also generates Dart output).
When the browser finds this (currently redundant) Dart script tag it produces this output. When you want to get rid of this message just remove the script tag from the HTML page in your your_app_package/build/web/index.html file.
EDIT
transformers:
- $dart2js:
'minify': true
commandLineOptions: ['--output-type=dart']
or
commandLineOptions: ['--output-type=dart', '--categories=Server']
I haven't tested if this categories argument has an effect in dart2dart too.
EDIT END
EDIT2
There is also the output type dart-multi which creates one output file per input library.
See https://code.google.com/p/dart/issues/detail?id=21616#c9 for more details.
EDIT2 END
Add the following lines to the pubspec.yaml file of your package (thanks to Günter, who pointed this out):
transformers:
- $dart2js:
'minify': true
commandLineOptions: ['--output-type=dart']
Then run pub build with the option --mode=debug.
This results in a "runnable" Dart application, containing the dart sources and the needed packages. The build directory can then be copied to a location visible to your web server. When loading the corresponding URL in the Dartium browser the application is started.
Is it possible to use Dojo build without the need to modify JavaScript files?
The article dgrid and Dojo Nano Build provides the instruction to create the build, but it requires adding the following line into JavaScript file, which initializes the application:
require(['dgrid/dgrid'], function () {
(replacing 'dgrid/dgrid' with your build module name).
However, it is very problematic when using build for own modules, because, of course, in development mode the require with own layer can't be included, otherwise the modifications made to own modules wouldn't be visible. But in production mode this line must be added.
So either you must modify the file manually before production build, or write a script that would modify the file during the build. Both are very error-prone.
Is there a better way to achieve that result? Is it possible for Dojo to recognize that the build is provided and should be used, instead of loading each module separately?
The following line of code can be included in both development and production modes.
require(['dgrid/dgrid'], function () {
I describe the reasons why in my answer here.
What you need to do is configure Dojo differently based on what environment.
In a blog post that I wrote, I describe this in more detail. The following summarizes the post:
I create three modes: Production, Uncompressed, and Development.
Development
When developing code, I will have the js source linked into the web server and the Development mode will point to the dojo.js file and the raw css file(s). The browser will load modules that I need using xhr. And I point to the top level css files which import other css files. The result is that a lot of requests will be made to the server and the loading of the page will be noticeably slow. The benefit is that you can see development changes without having to do a full build.
Production
Production mode points the main dojo file at the dojo.js that is built using the build tool. I also create <script> elements for the other layers that are needed in the page. I point the css to the built css files which the build tool has inlined the imported css. The page loads quickly, but it is difficult to debug
Uncompressed
Similar to production, but I point to the .uncompressed.js files. Production and Uncompressed are available in the released version of our software. I use uncompressed when trying to troubleshoot an issue in a production environment. The value of this mode is dwindling as the developer tools are better supporting compressed javascript (ie source maps, etc.)
Server side
The default mode is Production, but I use a query parameter to switch modes. I also store the current mode in the session, so that I only have to set the mode once to change it. Subsequent pages will run in the changed mode, until I change it back.
Here is a java implementation of this code.