Anyone already used https://reimagined.github.io/resolve/ and got hot reload for react working?
Cheers
-raf
TL;DR
This small DIFF (3 files) for the HackerNews example application illustrates how to implement the simplest HMR:
* On Diffy: https://diffy.org/diff/kgfz1h97zr9sisxcfkb0m5cdi
* Permalink: https://pastebin.com/hv87aquw
hacker-news/client/hmr.js
hacker-news/client/index.js
hacker-news/config.app.js
Complete answer:
Although the reSolve frameworkâs examples mostly use React, it is up to you how you implement the frontend, so you can implement custom logic to support hot reloading.
Also, note that the reSolve framework supports automatic rebuilding of server bundles and custom client sources specified in the application config as in the following code sample:
https://github.com/reimagined/resolve/blob/master/examples/hacker-news/config.app.js#L49-L67
So, you can take one of the following two approaches to implement hot reloading in your reSolve-based application:
1) Implement an SSR renderer for your application, like in this example: https://github.com/reimagined/resolve/blob/master/examples/hacker-news/client/ssr.js. You can even use a simplified version of this file containing only imports - it will suffice for the task. The main point is that this SSR renderer is rebuilt automatically after any of UI source files is changed, which you can use as an indication of file changes. On the client side, you can send long-polling requests to this handler and invoke page reloading on a change.
2) Generate a fully custom frontend using a builder that provides hot reloading out-of-the-box (for example, create-react-app), and link that frontend to your reSolve application as in the following example:
https://github.com/reimagined/resolve/tree/master/examples/with-vanillajs
I am after something like
firefox['update'] = "never" equivalent in cookbook recipe for firefox as auto updates is causing issues with selenium tests. Could someone please help?
Looking at the attributes provided by the cookbook reveals the following:
default['firefox']['version'] = 'latest'
So setting this to some specific version would be a starting point (not sure if you have set this, as you seem to lack the knowledge how to find the attributes provided by a cookbook.
Regarding actually disabling updates, a quick search revealed this thread, which lists the option that needs to be added to the user.js file in your profile:
user_pref("app.update.enabled", false);
Does anybody know what if direct update updates everything that lives in the common directory structure. I used the same code base for multiple apps, the only change being certain settings within a js file that tells the application how to act. Is there a directory i can put that js file that would be safe from the direct update feature?
I cant seen to find any specific information on IBM's website.
I think you guys need to be careful which terms you are using in order to not confuse people who may be looking for similar help.
Environments are specific to the OS you are using. iOS, Blackberry, Android, and etc. environments.
Skins are based on the environment, and aren't generic to all platform. When you create a skin you must choose which environment you are running in.
So to correct some, direct updates will update all skin resources in targeted environments.
For example: You have an app with Android and iOS versions
When you create skins, you are creating essentially a responsive type of design to your parameters. For instance, if you have a 2.3 vs 4.2 Android OS, you can set a look and feel for both. However, these utilize a single web resource base. The APK would be the same for both versions of the app (by default) and have 2 available skins. On runtime utilizing IBM Worklight's 'Runtime Skinning' (hence the name) it goes through the parameter check for the OS and loads that skins overriding web code.
You could technically override all of the web code to be completely different for both skins, but that would be bulky and inefficient.
When you direct update you are updating all the resources of that particular environment (to include both skins), not the common folder/environment.
So an updated Android (both skins) would have updated web resources (if you deployed the android wlapp) and an iOS version would stay the same.
If you look at the Android project after build (native -> assets -> www -> default or skin) you can find the shared web resources generated by the common environment. However that is only put there every time you do a new build.
In the picture, I have an older version of the Android built for both skins on the left. On the right is a preview of the newer common resources after deploying only the common.wlapp. So you can see that they are separate.
Sorry if it was long winded, but I thought I would be thorough.
To answer the original question, have you thought of having all the parameters of the store loaded from user input or a setup? If you are trying to connect to 3 different store, create some form for settings control that will access different back ends or specific adapters. You could also create 3 different config.js that load depending on the parameters that you set so that you set. The other option is to set different versions of your apps specific to the store.
Example. Version 1.11, 1.12,1.13 can be 3 versions of the same app for store 1, 2, & 3. They can be modified and change and have 3 sets of web resources. When you need to update, jump up to version 1.21, 1.22,1.23. It seems a bit of a work around, but it may be your best bet at getting 3 versions of the same app to fall within the single application category. (keep 3 config.js types for modifying for the 3 stores).
To the best of my knowledge Direct Update will update every web resource of the skin you're using (html, css, js). However, I'm no expert with it.
If you're supporting only Android and iOS applications and need a way to store settings I recommend JSONStore. Otherwise look into Cordova Storage, Local Storage or IndexedDB.
Using a JSONStore collection called settings will allow you to store data on disk inside the app's directory. It will persist until you call one of the removal methods like destroy or until the application is uninstalled. There are also ways of linking collections to Worklight Adapters to pull/push data from/to a server. The links below will provide further details.
the only change being certain settings within a js
Create a collection for your settings:
var options = {};
options.onSuccess = function () {
//... what to do after init finished
};
options.onFailure = function () {
//... what to do if init fails
}
var settings = WL.JSONStore.initCollection('settings',
{background: 'string', itemsPerPage: 'number'}, options);
You can add new settings after initCollection onSuccess has been called:
settings.add({background: 'red', itemsPerPage: 20}, options);
You can find settings stored after initCollection onSuccess has been called:
settings.findAll({onSuccess: function (results) {
console.log(JSON.stringify(results));
}});
You can read more about JSONStore in the Getting Started Modules. See Modules: 7.9, 7.10, 7.11, 7.12. There is further information inside the API Documentation in IBM InfoCenter. The methods described above are: initCollection, add and findAll.
Since version 5.0.3 I think, direct update will not update all the webresources, only those of the skin you are using.
say you have skin def and skin skin2
you are on def
make change to def on the server -> you will get a direct update for
def only
make change to skin2 on server-> no direct update for you.
you are on skin2:
make change to skin2 on server -> direct update for skin2 only
make change to def javascript which also resides on skin2 ( and therefor end result is def+skin2 concatination), update only skin2
make change to def,just to a picture(also checking pic extension from application-descriptor: ") -> no direct update
Thats how direct update works.
Please also share some more details about what is the problem, I see you use a js file, where do you change it? what do you mean excatly, give a better (simplified) real life example, because it is unclear what you are trying.
Is it possible to disable the new the explain functionality in Rails 3.2 globally via configuration? I'm using activerecord-sqlserver-adapter 3.2.1 and there appear to be some bugs with the explain (show plan) portion of the gem.
To cite from http://weblog.rubyonrails.org/2011/12/6/what-s-new-in-edge-rails-explain/
New applications get
config.active_record.auto_explain_threshold_in_seconds = 0.5
in config/environments/development.rb. Active Record monitors queries and if they take more than that threshold their query plan will be logged using warn.
[...]
By default the threshold is nil in the test and production environments, which means the feature is disabled.
so just set
config.active_record.auto_explain_threshold_in_seconds = nil
You can disable auto-explain by setting config.active_record.auto_explain_threshold_in_seconds = nil in your config/environments/development.rb
You should note that config.auto_explain_threshold_in_seconds has been completely removed in Rails 4.0 & 4.1. In 4.1 it will throw a full error.
See https://github.com/rails/rails/pull/9400/files
If you upgrade, comment that line out.
I'm new to testing and I'm trying to create a test for my Plone product for the first time.
I'm on Plone 3.3.
The basic test suite works, I can execute it without errors.
I followed this documentation : http://plone.org/documentation/kb/testing
...except that I'm writing my tests in Python classes instead of doctests.
My problem is that I cannot seem to access the views defined in my app (I get ComponentLookupError).
The problem seems to be with the "browserlayer" defined by my applications.
When I remove the layer="..." attribute from my configure.zcml, the test can access the views without problem. However, if I add it back, it doesn't work.
I guess that's because de browserlayer interface doesn't get applied to the request.
The only reference to this problem I found is in the tests for googlesitemap : http://dev.plone.org/collective/browser/googlesitemap/googlesitemap.common/trunk/googlesitemap/common/tests?rev=
The author seems to have made a custom ZCML file for the test, in which the layer="..." attribute has been removed. (which would work but it seems very bad having to maintain a separate zcml file for the tests)
In my test, I have included the following (taken from the googlesitemap tests), which passes :
from jambette.site.interfaces import IJambetteLayer # this is my browserlayer
from plone.browserlayer.utils import registered_layers
self.assertTrue(IJambetteLayer in registered_layers())
So I think my skin and browserlayer are registered correctly.
Is there anything I need to do so that the browserlayer will be applied to the request?
Browser layer interfaces are simply 'painted' onto the request with directlyProvides. Simply do so in your test setup before you look up the view:
from zope import interface
from jambette.site.interfaces import IJambetteLayer
...
directlyProvides(request, IJambetteLayer)