I am trying to get my Dart Polymer 1.0 single page app working with pushState. I have set up nginx to route all requests to the dev server which runs when executing pub serve. Nginx also takes care of always requesting index.html instead of the real url.
The problem I am facing is that as soon as I load a url with at least one folder, the js cannot be loaded anymore.
Example
Requesting project.local loads the index.html file and works fine. The same is true for project.local/test. As soon as I try going to project.local/test/something, it stops working because the file index.bootstrap.initialize.dart is requested from project.local/test/index.bootstrap.initialize.dart and not from project.local/index.bootstrap.initialize.dart.
Source code
The whole project can be found at https://github.com/agileaddicts/blitzlicht. The index.html is where the magic happens.
How do I tell the transformer to put absolute urls into the html instead of relative ones?
you should by able to upgrade to the last version of polymer by changing the version of reflectable.
reflectable: >=0.5.0
and perhaps add this in you pubspec
- $dart2js:
$include: '**/*.bootstrap.initialize.dart'
Related
I am experiencing something in production which isn't reproducible locally.
The Link from nextjs (version 12.3.x) works well in development and when running the build in production mode locally, meaning that the navigation happens without a full page reload. But when deployed with terraform, all Link components are causing a full page reload. Everything else works as expected.
I have a mixture of Link children across the application, sometime it's a, but other times it's a button or simply a div or span. In every case, the full page refresh happens. That's why I suspect it must be something related with the configuration rather than the Link usage, however I am not sure where to start debugging and I am looking for a hint in the right direction.
Back with an answer to this. In my case, nothing was wrong with the Link components itself, nor with the build. The problem was with a path rewrite in our terraform configuration (it was rewriting everything in /_next/*).
It appears that getServerSideProps fetches JSON files which will be used to render the page Their paths were being re-written and causing a 403 error, which made the page reload instead of allowing me to navigate seamlessly as I am used to with next.
This problem was very specific to my configuration, but my general recommendation is to check whether you are rewriting any path of the json files created by next at navigation, in case you are experiencing the same problem only on staging/production.
I have a nice html, css template (source code here).
I am going to use this template in my angular2 app (source code here).
I got the html template out of this repository (index.html).
My problem is in the angular2 source code
You need to clone the angular source.
Run npm install
Run ng serve
Unfortunatly, it seems that the <script src="assets/js/main.js"></script> in index.html is not added properly. Although, there is no error in the console, the left menu is broken. I know that this problem occurs when main.js is not fit.
Here is the correct html page:
Here is the angular page (broken header and menu):
The codes are identical, but I have decomposed the html template into 3 components (header, menu, and app (main content)).
Instead of trying to figure out what happened with your CSS, I took the original template, converted it to Angular 2 with the angular-cli, and fixed the CSS issues. It all works now, and the complete source is at https://github.com/Boyan-Kostadinov/angular2-miminium
When you broke apart index.html it's likely that you also altered some file paths.
The relative path would go from src="assets/js/main.js" to something like src="../assets/js/main.js".
Prepending ../ to the path will back out of the current directory to the next level up. As you have it now, the browser is looking for the assets directory in what I assume you have compartmentalized as an htmlComponents directory.
Consider using the absolute path to main.js, at least to diagnose the issue.
I ran into a similar issue with the same file. In my case, I have a complicated application that is developed in stages. I installed my Angular seed in a subdirectory. Because of my file structure, when I run npm start, the live server that is started has bad relative link locations. For example, in the screen shot below, you will see that the application is trying to find style.css at http://localhost:3000/medface/RecordWriter/styles.css; however, it should be looking at http://localhost:3000/styles.css, because the root of the web server that was created by npm start is at /medface/RecordWriter/.
With respect to your project. The key to finding the problem with your link is to open the developer panel and inspect the actual network request. If you share a screen shot, we may be able to help you inspect your instance with more insight.
What Worked for Me
In my case, I reconfigured my local web server to handle any unserved pages in the Angular2 folder and return the index instead. When I run npm start, I close the browser page that opens and use my regular web server. Instead of viewing my application on localhost:3000, I view my application at localhost/medface/RecordWriter/ (which is equivalent to localhost:80/medface/RecordWriter).
The down side to my makeshift approach is that the page must be refreshed before changes appear, but it loads all resources predictably and reliably, and allows my Angular2 code to run in conjunction with some of the older code base in other areas of the website that have not been converted to Angular2. Regardless, this may work for you also.
I have a single page application that does not use hash URLs I want to use the history API. I am using the middleware historyApiFallback() in browserSync server options. However, this is only working for one level deep URLs:
http://localhost:3000/main correctly resolves to index.html
BUT
http://localhost:3000/main/a is NOT working. The browser shows "connected to browser sync" and then a blank page is displayed.
Anyone knows what could be the issue here?
The issue was that the URLs for js and css resources weren't correctly setup. This post helped me fixed the issue: mod_rewrite to index.html breaks relative paths for deep URLs
When running my website locally (via yesod devel) the styling loads up and all is good.
CSS files are loaded correctly. Using this method
But when uploaded onto my amazon ec2 server styling is not loaded correctly.
I'm using nginx that listens to port 80, then redirects it to port 3000 where my yesod webapp is running. My nginx.conf settings.
So I can directly got to header.css showing that the static files are passed on to the user browser. However, for some reason the css is not connecting correctly.
Another thing I've noticed is that if I directly go to the IP and port 3000, the default favicon.ico icon will get loading, whereas if I go to the domain it will not get loaded.
Any ideas?
Does the approot setting in config/settings.yml agree with the start of the url you were using to access the ec2 server? The log you show could certainly be explained by it being wrong. Yesod builds in fully qualified urls, using the approot as the prefix, for all of the additional pieces needed to build up a page. (Check the page source to see what Yesod has produced.)
If you are running using yesod devel for now, the approot setting will be the one set for the "Development" environment - which will be the one in the "Defaults" section if you have kept the structure of settings.yml as it was when you created your scaffolded site.
Found nothing seriously wrong on your nginx.conf file.
I hit http://www.finance-web.biz/static/css/header.css and the result is fine.
/*!
* Extra header style
*/
.beta {
color: #CC3300;
}
Maybe it's something cached in your browser.
I've done a lot of searching and not found anything like this, but I might not be using the right terms. My problem is this:
On a Tomcat 6 server, I originally deployed a Spring Webflow app with a context root of fred - to access it people went to myserver.com:8080/fred
The Spring code in that app changed all requests to have /spring after the context root - so the URL above would become myserver.com:8080/fred/spring - and this would bring up the index page.
That was all fine & dandy.
I rewrote the app to use Spring MVC instead, for reasons too boring to mention here, and as part of this removed the code that performed the /spring piece.
I am now trying to deploy it to the same Tomcat instance. It appears to deploy fine (after undeploying the old one).
However when I try to hit myserver.com:8080/fred to get the index page, it redirects to myserver.com:8080/fred/spring, and naturally this fails as that URL is not supported.
I've checked my config within the WAR, and also scanned through the following places in Tomcat:
conf directory
conf/catalina and subdirectories
webapps and subdirectories
work and subdirectories
I can't see anything referring to this /spring url rewrite. It does deploy and work successfully on my local version of Tomcat.
Could anyone offer any suggestions? All help is appreciated.
Sounds like your browser cached the redirect. If your site at myserver.com:8080 used hard redirects (301 Moved Permanently) to send users from /fred to /fred/spring your browser will remember that the next time you access the application. Try emptying the browser cache and trying again.
That would explain why everything is dandy on your local machine