We have an application written entirely dart/polymer with quite a few polymer components. We use the custom tags in out index.html and compile to dart with pub build. The compile to javascript creates index.html of 24K lines. Original index.html is 150. The application works perfectly.
However we would like to distribute the code to third party sites so that they also can use the components with custom tags. Ideally by just linking to an already compiled script and simple using our custom tags in their pages.
I know this is possible without polymer. Question is does polymer support this? Is it possible to compile a polymer app and keep to a minimum amount of changes in the html file?
To reduce the problem to an example:
We would like our customers to be able to do some thing like this, without the use of dart sdk:
<head>
<script src="what_ever_required.js"></script>
<script src="our_application.js"></script>
</head>
<body>
<our-custom-tag></our-customer-tag>
<p>What ever else content</p>
</body>
Regards
That's currently not supported.
Currently an application that used Dart code needs to be compiled to JS as a whole at once. There is no way to build parts of a Dart application and compose an application from them later.
With the upcoming DDC (Dart Development Compiler) there might be a way to accomplish that. An experimental approach is https://pub.dartlang.org/packages/polymerize
Related
Then working on my new Vaadin 14 based application Intellij cannot find the built in lumo theme variables...
These variables exist at runtime in my browser, but where can I point Intellij to see them?
It looks like it's not possible, at the moment, unfortunately.
The problem is that starting from V14 styles you want to reference are packaged as.js files, but styles are written in .css. For example, if in V13 you could import them in your template like this Sizing and spacing:
<link rel="import" href="bower_components/vaadin-lumo-styles/sizing.html">
This would be the current way in V14 instead, which is a js file:
<script type=“module”>
import “#vaadin/vaadin-lumo-styles/sizing.js”;
</script>
So you can use those custom variables in your styles without problems, as long as you load an appropriate js module on your page (like this #JsModule(value="#vaadin/vaadin-lumo-styles/sizing.js") Lumo), but I haven't found a way (and not sure there is one) to make Intellij aware of them.
So the underlying problem is that you can't import a variable from a js file into a css file.
I'm using the sample here to embed a Power BI report into a web application.
The application compiles properly, but I'm getting an error involving Promises. I've tracked down the solution here. It seems that I need to add the following somewhere in my application:
<script src="https://npmcdn.com/es6-promise#3.2.1"></script>
However, I have absolutely no idea where this script tag should go. Any suggestions? Thank you.
The es6-promise library is a polyfill for Promises, mostly used in IE.
If you need it, you just need to put it anywhere in your <head> tag, preferably before your <script src='.../powerbi.js>.
For more info on es6-promise: https://github.com/stefanpenner/es6-promise
I am currently working on a project in which we are having a React/Flux UI being developed for us. I am being told that the UI code needs to be converted into GSPs and put into a Grails Project, to work with our backend. I feel like moving the UI into GSPs will nullify the use of our Flux implementation(Reflux).
My initial thought is that this is wrong and I have not found any use of Grails and Flux through searching.
I'm involved with a production Grails application which uses React as it's front-end. There's no need to "convert" the React/Flux code into GSP - in fact that would largely sacrifice the benefits of the React UI. There's no need- Grails is very well suited to provide a robust Restful backend to a React (or Angular, or any other JS framework) application.
Depending on your application needs, you will probably want to provide a restful API for the front-end to consume/post as needed. Use URLMappings.groovy to specify endpoints that the React app can access. You will likely choose to use JSON as the medium to send data to the React app - Grails' JSON views are a fast, flexible and straightforward means to render Grails domain objects or other data to a JSON payload.
There shouldn't be anything Grails-specifc regarding Flux - use it to manage and mutate your state in the React application, perhaps by making rest calls from your Flux dispatcher (or action creator) to the Grails backend to retrieve data and update your Flux store.
Regarding GSP, my recommendation is to simply have a barebones GSP view off your main controller, which simply loads the Javascript needed to run your React app. If you are using a module bundler like webpack, this can be as simple as linking your bundle.js file into your view and providing the root element specified in your top-level component:
<html>
<head>
<title>My App</title>
</head>
<body>
<div id="app"></div>
<asset:javascript src="bundle.js"/>
</body>
</html>
Note that for this to work, you must be outputting your webpack bundle into grails-app/assets/javascripts, which I find to be the simplest way to load the React application in a Grails app. Using this approach, there's no need to load React, Flux or other related libraries into Grails directly - just build your project using the standard JS toolchain (using npm/package.json to manage your dependencies), and process/bundle the entire application into a plain JS bundle that can be loaded by the Grails asset-pipeline.
React makes a great choice as a view-focused Javascript library that doesn't make a lot of assumptions about your backend architecture. With a solid restful api based on Grails, and some intelligent choices about tooling and project structure, React is a great fit for a modern, single-page Javascript UI in a Grails app.
Why would the use of GSP nullify the use of React or Flux? GSP is just a server-side processing language that renders HTML. Last I checked React and Flux make good use of HTML for a great number of things in combination with Javascript.
You can use them together without any issues. How, is up to you.
You are being told wrong. GSPs are Java servlets. The only reason to mix React with a server-side technology is for an isomorphic application, where you would compile your JS prior to returning/pushing it to the client. In which case, you would need to create something akin to a Rhino-based servlet. Otherwise, treat it as you would treat any other static asset.
I am building a client/server app in Dart using Angular for the front-end and Shelf on the backend. When I do a pub build it generates the javascript for the Dart files as expected but is does not replace the dart references in my HTML files. So in my index.html I have the following script reference:
<script type="application/dart" src="main.dart"></script>
This makes my application not load correctly. If I manually change it to
<script src="main.dart.js"></script>
My application works as expected. My question is, is there a way to configure my pub build to do this automatically? Or are dart files references not supposed to be replaced with JS references? If so, how do I build a basic server?
I know this produces an error message in the browser console but never experienced any problems because of this.
I haven't used it myself yet but I think this transformer https://pub.dartlang.org/packages/dart_to_js_script_rewriter does what you want.
We would like to make jquerymobile lighter by removing modules we dont need.
Want to keep only some widgets, ui control decorations and touch event processing.
Would also like to use Zepto instead of the full jquery library...
Thank you!
jQM is now decoupled:
http://jquerymobile.com/blog/2011/08/03/jquery-mobile-beta-2-released/
Widgets: Now decoupled for flexible builds
We’ve wanted to decouple all our widgets from the page plugin for a
long time now and we’re happy to announce that we finally landed this
change. So what exactly does decoupled mean anyway? Well, the
individual widgets and utilities have always been broken out into
separate script files. However, the page plugin was responsible for
handling the auto-initialization all of the official plugins found in
the markup at page creation. This situation made it impossible to
remove plugins you don’t need without causing errors, and generally
set a bad precedent for future widget additions.
Now, pretty much all the UI widgets in the jQuery Mobile library are
completely decoupled so they can simply be deleted if not needed for a
particular project. This change allows you to dramatically reduce the
size of the library by only including the specific set of widgets or
features you need, in addition to the handful of required, core files.
While we still plan to do more decoupling and cleanup, the following
files are now decoupled and can safely be removed from the make file
before you do a custom build:
page header/content/footer
collapsible
controlgroup
fieldcontain
fixheaderfooter
button
checkboxradio
select
slider
textinput
links theming
listview
navbar
grid
We will work on a dependency map because a few widgets rely on others
to work. For example, the button markup plugin is called by many of
the widgets above, so it can only be excluded but if you’re not using
any of the widgets that depend on buttons.
We’re still working out our recommendations for mapping plugin
dependencies and decoupling things even further. Ultimately, this will
be surfaced in a download builder tool, so stay tuned!
You can head over to their GIT Repo and just download what you want:
https://github.com/jquery/jquery-mobile/tree/master/js
Not sure if you're just looking for event support, but this worked for me:
<script type="text/javascript" src="js/jquery.mobile.define.js"></script>
<script type="text/javascript" src="js/jquery.mobile.core.js"></script>
<script type="text/javascript" src="js/jquery.mobile.media.js"></script>
<script type="text/javascript" src="js/jquery.mobile.support.js"></script>
<script type="text/javascript" src="js/jquery.mobile.vmouse.js"></script>
<script type="text/javascript" src="js/jquery.mobile.event.js"></script>