Figwheel has the great feature where it will reload all code, except for code defined in a defonce expression. This is great because you can persist application state as you code.
However, I'm in a situation where I want to change values in my defonce block. How do I force Figwheel to reload all of my code including the defonce expression?
Just change it to def, save to reload the code, and undo it back to defonce. That should do it!
If you want to reload a lot of code refreshing is better usually.
Related
I'm trying to test changes to our website, which is a dynamic application. When making edits to certain elements, the visual editor gives a warning:
"The number of elements selected changed after the page was initially loaded. Make sure that your changes appear as expected using preview mode." I've read all the official Google documentation on this specific warning. See the layout here
I've enabled activation events, set it to optimize.activate and made sure it is being pushed to dataLayer.
When I preview in debug mode, it says the experience was applied, the activation event was triggered on 'optimize.activate' and the url matches. Yet only one of the changes have been applied. See here
When I open the console and call dataLayer, optimize.activate is right there.
I'm honestly baffled. I read here that filters on the Analytics view linked to your Optimize container can stop events 'showing up'. We use filters to IP block our staff from showing up in our Analytics data.
Any help on this would be amazing.
p.s. I'm not a developer so go easy on me :)
Ok this maybe for a couple of reasons... I've had a few instances where I can view changes in preview mode:
First of all, if you're viewing changes in incognito mode, you need to make sure the following option is switched off in your browser - Block third-party cookies. If this is switched on, then in preview mode, your browser will block the Optimize 360 cookie and your experiment will not run. (This means you will not see your changes).
Secondly, if you have Audience Targeting set, these features do not work or show in preview mode.
Thirdly, your test may not be firing on the correct event trigger. EG pageload. So make sure the correct event is attached to your AB Test. As you will be able to see the changes in edit mode, but again not in preview mode.
Your issue is likely to be point 1 or 3.
I have a weird situation. One of my users is using functionality of Chrome (current version, 49, 50), that he drags and drops a file from his folder on local computer to normal input type=file button in a form on the webpage. Once again, let me stress it even more, its normal html input, no fancy javascript, no drag&drop events and handlers, nothing like this. It just takes the name of the dragged file and puts it into the input field, as like he selected it via "normal" way, opening the file select window, locating file on harddrive, selecting the file and confirming.
In some specific situation, this stops working (while doing some edits in the page via javascript / ajax), and I need to "reenable" it.
But, and that is my question, I haven't found any documentation of this "feature" in Google Chrome (or maybe some other browsers as well, I don't know). Why it works, how it works, how it should work and what to do if it stops working :) Does anyone has any experience with this ? The only way how to "fix" it now is to reload the page. I'd love to solve it ... :)
EDIT 1 : I just did a quick test, it works and bugs the same way in Firefox on Win. It doesn't show any error in dev console or any message, it just doesn't add the file as expected.
I've found it. The previous discussion with deceze pointed me to test the javascripts I have on the page, that do not "interfere" with the input type=file ... they weren't any such scripts, but I've found that after doubleclick on the table (that I'm using for editing) this script is being called
$(document).bind('drop dragover', function (e) {
e.preventDefault();
});
and there wasn't any unbind action when table is saved ... this caused the drag and drop everywhere on the page to stop working after the edit.
I am referring to the save feature in the 'Sources' panel of the Chrome Dev Tools. I have been using this feature for a long time in the stable release of Chrome, but after installing the build from the developer channel, I notice that once I have saved the file the first time, Chrome no longer prompts me to save and just does it automatically after every change I make.
This is quite a pain, as I make a lot of changes experimentally in the dev tools whilst debugging which I don't wish to save, I would like Chrome to save the file only when I explicitly tell it to.
Does anyone know if there is a way to disable this automatic CSS saving?
(Apologies for no screenshot, my PrtScn key seemingly won't operate when I am in a context menu)
Update:
I have reverted to the current stable build, 27.0.1453.93, and the behaviour appears to be the same.
I am having the same problem, I can only offer workarounds: use another browser, such as Firefox, for doing tests!
Alternatively you could launch another instance of Chrome with a different profile. You could also launch a Chrome "Incognito Window", it seems to not apply the filesystem mappings.
I normally use an Incognito Window or inline styles to test changes.
Alas, I learned after reading a post by Google's dev relations person
that the automatic save cannot be disabled and it seems that's the way
it's going to stay.
html5rocks.com/en/tutorials/developertools/revolutions2013
– tommypyatt Feb 21 '14 at 14:22
While not solving the issue directly, it is a decent work around:
In Chrome, in the css inspector you can click and hold the + button, then choose to add your changes to the inspector-stylesheet. It's not as convenient as directly editing in your css-selectors, but what you write will all be in inspector-stylesheet.css, so not saved to your project. Then when you are happy with your changes, you can manually put them in to your css.
Problem context:
I have a C++ program and a web presence. Currently the way things are working I have made a control panel with javascript and html. And it send commands via an unimportant communication medium to control things or get information from the C++ program.
Now, when the C++ program launches, I'm making it run a
ShellExecute(NULL, "open", addressBuffer," --new-window", NULL, SW_NORMAL);
This is a way of launching the default browser with the given address. The addressBuffer in this case points to an intermediate HTML file that quickly turns around and uses the
window.open()
in Javascript to open the final popup, then closes itself.
The result is the user now has the popup control panel that I want them to have but the user's main browser window also gets given focus, un-minimized, and placed on a different tab than the one they had selected. (Basically pops up out of nowhere and selects a another tab)
Problem:
I'm looking for a way to launch a Chrome popup, without disturbing a previously open browser window. Any ideas or solutions would be very helpful.
Lastly, it's worth noting that the " --new-window" from the code above doesn't actually open a new window like you would expect. In this case it's actually doing nothing... If it did work, none of this would really be an issue.
I know this is wordy so thanks in advance for you time!
-Michael
Alright, I came up with a solution.
Something about how ShellExecute processes it's commands was preventing the command line args to be passed in correctly.
My work-around includes grabbing the path to Chrome from the registry,
HKET_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe
Then simply doing a system() command with the chrome path "--new-window" and the web path.
Then I let the intermediate html page open it's popup and close itself.
Tada done.
Thanks.
If I don't implement any updateready event handler and don't call swapCache(), does that mean that the browser will always use the first (oldest) downloaded version of the application?
If no, then why is the swapCache() method needed?
Swapcache makes sure that "subsequent" calls to cached resources are taken from the new cache.
Subsequent meaning after swapcache.
To see this in action try setting the src property of an img dynamically after the
swapcache call in the updateready event (so that the browser loads it at that particular
time). Make sure this image is not already loaded elsewhere in the page since that will
distort this test.
Now change the image and change the manifest files (to force reloading the cached files).
Reload the page in your browser.
You should now see the new version of the image in your rendered page.
Now comment out the call to swapcache.
Make a change to the manifest file and reload the page and thus all resources.
Refresh the page again (to make sure you have a version from the new cache).
Now change the image again and change the manifest.
Again reload the page: now you see the old version of the image.
In the last case, the browser finished loading the new versions in cache, but since
swapcache was not called, the image was still taken from the old cache.
If you do not do any dynamic loading of resources in your page, the swapcache has no effect.
In particular, if you reload the page in the updateready event handler calling swapcache
first has no effect since reloading the page will get it from the new cache anyway.
I have an app with a pretty large cache (>100mb). This takes a particularly long time to swap the cache in (and pretty much locks the browser while this is happening). So I display a message indicating that the app is updating (please wait...), then call swapCache(), then display a new message when it's done indicating completion.
Not sure if this answers your question (as to why it's necessarily needed), but I think it provides a valid use case for swapCache() at least.
Let's imagine 2 different scenarios.
You call location.reload() when the new content is available. The page will reload using its all-new content. applicationCache.swapCache() is not needed in this case.
Your user continues to interact with your page, without any reload. This interaction causes an asset to load dynamically. For the sake of argument, let's imagine that it's a rollover image, and let's imagine that you have just updated this rollover image. Without applicationCache.swapCache(), your user will continue to see the old rollover image. After applicationCache.swapCache(), s/he will see the new rollover image.
So applicationCache.swapCache() without a reload says: "Keep the page looking the way it was when it was loaded, but use any new assets now, as soon as the page asks for them".
The SwapCache method provides a mechanism for the application to be in control of how an when updates are applied. In regular HTML apps, it can be difficult to determine if the correct JS is present on the clients browser.
Also browser implementations vary on when a cache would be updated, I found the iPhone particularly stubborn. swapCache put me back in control of how my app is updated i.e. I could choose to automatically apply the patch or let the user choose when to apply etc.
I was wondering the same thing. I seem to be able to trigger a successful update by just calling "window.applicationCache.update()". If the manifest file has been modified, the 'download' event is triggered, then eventually the "update ready".
When I reload it, it appears to have been applied. I don't seem to need to call swapCache(). I have provision for calling it from the app, but so far have not noticed any effect on the update process.
Calling update() basically eliminates one reload, AFAICS.
swapCache will switch from the previous set of resources listed in the cache manifest (when the running webapp was loaded) to the new set. You are doing this in response to an updateready after all, which signals that a new manifest has been loaded.
This is not to be confused with loading individual resources, for which the usual browser caching policies still apply. In other words you will swap set of resources, but individual resources need their own cache management to ensure they're reloaded when you need them to.
I haven't tried this yet, but it would seem to suggest structuring the code as an "update controller" javascript file that handles the update process, and javascript sources with a versioned filename (or URL) with known entry points.