I was reading several style guides on using react on the server side, and they all (rightfully) seem to suggest that components should be a pure function of states and props.
That begs a question that if I were to use a DOM API, say window.innerWidth or canvas.getContext(), which is the best place for doing so according to the react + flux philosophy.
componentDidMount will only executed in client side, you can place browser-specific code there.
But if it's not enough, my recommendation it's use DefinePlugin if you prefer webpack as your build tool.(I believe there are plugins provide same feature if you prefer other build tool)
new webpack.DefinePlugin({
__CLIENT__: true
})
And use conditional statement to judge whether the code is executed in browser environment.
Related
Looking at some of the sample code for hybrid mobile apps that speak to Node.js on BM (http://mbaas-gettingstarted.ng.bluemix.net/hybrid), you will see various examples that demonstrate how to use a logger on the client side:
var config = {
applicationId:'<applicationId>',
applicationRoute:'<applicationRoute>',
applicationSecret:'<applicationSecret>'
};
IBMBluemix.initialize(config).done(function(status){
// Initialize the Services
}).catch(function(err){
IBMBluemix.getLogger().error("Error intializing SDK");
});
I've confirmed this works fine in a Cordova app. My question is - why does this exist? As far as I can see, it does nothing more than wrap calls to console.log. It does not ever send logs to the Bluemix server app as far as I can tell.
There is documentation here, https://www.ng.bluemix.net/docs/starters/mobile/mobilecloud/nodejsmobile.html#log, that talks about the feature both server-side and client-side, but unless I'm missing it, there's no persistence for the client-side version.
If so - then what exactly is the point of this abstraction then? I have to imagine it was built for some reason, but I'm not seeing it.
this wrapper is used to "wrap" and to make "standard" the console log api, especially because this javascript API isn't available for all the browsers (especially old ones). By wrapping it the library could check the browser and its availability, in order to avoid an execution error
Another reasons is to wrap some configuration utilities, like providing different libraries to use (eg log4js) or other configuration, and so on.
Last but not least, probably it provide a singleton interface for performance optimization
So one of the neat features of languages like PHP is that you can include other files pragmatically and make a plugin-like system. I haven't seen an example of it yet, so I am not sure it is technically possible in Dart, but I would like to start designing a CMS that can load and unload plugins live without restarting or a fresh upload.
Currently it is only possible to load/unload code dynamically using Isolates.
In the browser new isolates don't have access to the DOM and it is limited which types can be passed between isolates. What can be serialized to JSON can be passed between isolates easily but for custom types you need to serialize yourself. I'm not sure about the actual limitations here though, this is work in progress.
In the browser the current limitations make it hard to make use of isolates. You can't load code into an isolate that imports 'dart:html' this prevents the use any browser API. On the server there are no such limitations.
This should all be improved but currently there are still a lot of limitations.
So far I built most of my UI and logic in QML with JavaScript without touching the C++. But now I need to make a RESTFul API call, based upon the examples I saw so far I must write the call code in C++ then "some how" (Am still figuring out that part) get it in the QML/JavaScript world....
Can't i make the API call etc completely etc in QML/JavaScript?
I am not an expert in REST but in theory if you could write the call in JavaScript running in a browser, you should be able to make the the same call using very similar JavaScript in QML/JS.
Having said that one of the things you want to do to maintain the responsiveness of your application is not run any time consuming routines on the event thread. Ensuring this is the case is quite easy in C++, I'm nos sure you could do that as easily in JS.
Finally it is relatively easy to get the results back to JavaScript world is quite easy. Qt and Cascades has a rich data modeling component set. QVariantList and QVariantMap types map into JS arrays.
I googled around and learned that Lift encourages view-first development, lazy loading of entities, perfectly interactive wizards and validators, built-in comet etc.
It seems to cover the territory of Backbone.js and its client-side (MVC) interactive rendering brethren (and also some interactive features of jQuery).
Does Lift make a lot of Javascript needed for (two-way) interactive web apps redundant, by being mostly self-contained? Where would I still need to apply Javascript libraries?
Lift uses jQuery (or YUI if you want) to do the client side interactions (Ajax, comet). But you don't see that most of the time. You can of course write JavaScript on the client side and call those functions from your server code using Lift.
If you really want to use frameworks like Backbone.js you can do that, and then use Lift as a REST backend.
But in general, if you want your application to perform some comet style updates or Ajax, Using Lift will save you a lot of time and headaches. And if you want full control over the JavaScript, you can get that too.
I like what I read about Lift, and I like the concept of Dart, but have little experience in both to be able to decide if thinking about using them in the same project is even making sense.
I want both writing structured client side code, and not having to worry about the OWASP top 10 as much
Can they work together? Does it make sense at all? Did anyone try?
I have integrated Dart with Lift using REST services together with Dart's XmlHTTPRequest and liked the result. I would say that any web framework that makes making RESTful services as easy as Lift does is a perfect match for Dart. On the other hand web frameworks such as JSF which requires components to take part of a advanced life cycle are probably not a good fit.
That being said, having the same language on the client and the server side is definitely a win, so when the Dart VM matures a bit more and starts to include RESTful functionality similar to what Express does for NodeJS then I would probably use that instead.
Already now baby steps are being taken for including HTTP support in Dart semilar to what Node provides on V8. Another important point for Dart is that it allows the browser and server to share rich objects, like what GWT does for Java, and this should further ease building advanced web applications with Dart.