In all of the demos I have seen thus far, Web Workers and Web Sockets apis seemed to use the "new" keyword in JavaScript. Is there another way to use these powerful tools without using the new keyword?
new is not dangerous. It returns a new object settings its prototype to that objects prototype and calling its constructor.
No where in the Mozilla dev docs does it say it's dangerous.
As answered this so question: is new harmful
I wish crockford et al wouldn't have said that because it gets boiled down to saying new is harmful and don't use it.
Use new. But don't forget to use new.
Related
Currently I am learning react. can anyone tell me what is the main application usage of react hooks and how can we take more advantage of using hooks with react.?
Basically, before if a component had state or needed to utilize a lifecycle method, we had to use a class, which requires a bunch of extra code.
Now that is not the case. With hooks, instead of ever having to use a class, we could just always use a function.
Tyler McGinnis wrote good blog post about it here
https://tylermcginnis.com/why-react-hooks/
I'm trying to write a new language detector plugin for i18next for integration with hapi. There's an existing hapi-i18next plugin that is quite old (it uses an extemely old version of i18next, 1.7.10 ) and so mostly useless. And the i18next API docs are pretty vague about how to write new plugins and exactly what the language detection process is. Does it run every time the t() function runs? should it be asynchronous? Has anybody else out there recently integrated hapi with i18next? I realize this is rather general but i'm not sure where else to turn.
Never used hapi so far, but seems hapi evolved a lot since version 8 (what's actually used here)
I don't know if that project is still maintained...
Perhaps you could try to create a new hapi-i18next plugin... (was not that much code)
To create a languageDetector plugin, it should not be a big thing... start here and continue by comparing how the express language detection works
In i18next the languageDetector is triggered here
...so on init/load and on a potential language change
I hope this helps.
What I ended up doing is writing a hapi server extension rather than a plugin, and a module that runs at startup that decorates the hapi server object with the initialized i18next object. The extension is installed to run onPreHandler and it basically clones the i18next object, attaches that instance to the request object, and detects the language (from the request header or from a query parameter), then sets the cloned instance to that language. This way, whenever a route handler uses the t() function attached to the instance that's attached to the current request, we know we'll be translating into the right language. Note that this is still for Hapi 16 (I need to port to 17/18 soon)...
A pretty specific query I know but one that hopefully applies more generally to the use of Autofac across the BotFramework SDK.
In the 'ContosoFlowers' sample, the DialogFactory class receives its 'scope' member, an Autofac IComponentContext, as its one constructor parameter.
However, I'm mystified as to where this comes from. I have an irrational hatred of DI anyway, but I still can't find some bootstrapper/service locator/module etc. that somehow links this to a concrete implementation. No obvious module. Is it baked in somewhere in the BotFramework code?
Also, can I ask what the purpose is of having all this DialogFactory.ContosoFlowersDialogFactory.Create() layer is? Say for example, when calling this.dialogFactory.Create<FlowerCategoriesDialog>()? This I assume is to avoid having to 'new' the dialog, and because the DI scope isn't available to the calling dialog? In that case, why have this factory injected into the RootDialog and not the IComponentContext scope itself?
Apologies if noob questions (very likely). Also please advise if there's a better place/forum for specific BotFramework samples code queries. Thanks!
Good questions! Let me try to address them:
IComponentContext. There is no registration/bootstrap of that interface. They are automatically provided by Autofac (see here).
ContosoFlowersDialogFactory. Your assumption is correct, the idea of having a dialog factory is to avoid having to 'new' dialogs manually, as that adds limitations around unit testing for example. Certainly, the approach you are suggesting is valid; and nothing prevents you to use the IComponentContext in the dialogs (please not that not only the RootDialog is using the factory, but also the other dialogs such as the SettingsDialog or the SavedAddressDialog). The reasons of having that layer could be subjective, so I would just provide you my point of view here. IMO, having these layers contribute to have a cleaner code and to avoid having DI's specific components across the application. In this scenario, the DialogFactory is the responsible of dealing with the DI layer, allowing you; to change the DI mechanism if you want; without having to update all the other components; or even in the case of a breaking change on Autofac; you will have just to deal with it in the factory. If I have to choose, I would prefer not having direct Autofac.* dependencies in my dialogs.
Recently I came across someone's code. The Alloy Markup is empty with just <Alloy />. In its controller, it adds a view using $.addTopLevelView().
How come I can't find any documentation regarding this function?
Good point. It might be because it's considered private, although it would normally start with _ to indicate that since JS doesn't actually support private methods.
It is also against the very idea of Alloy to not use the XML file for the markup but instead use "classic" Titanium code in the controller together with this method.
However, it might be a good idea to do a PR against the following file to request this to be documented:
https://github.com/appcelerator/alloy/edit/master/Alloy/lib/alloy/controllers/BaseController.js
I am trying to figure out how to setup a StructureMap3 configuration, that works in both a WebApi and in a Console application, like:
For<ISession>().HybridHttpOrThreadLocalScoped().Use(p => p.GetInstance<TestingContainer>().GetSession());
For console apps I would like the object to live as long as the thread lives, and for websites as long as the http-session lives.
This is possible with MVC websites because HybridHttpOrThreadLocalScoped use the HttpSessionState to determine whether to create a new instance or to reuse an existing instance.
WebApi doesn't have this HttpSessionState and therefore HybridHttpOrThreadLocalScoped won't work.
If I didn't care about the console app, then I would probably configure structuremap with Transient() or AlwaysUnique or similar.
So, what is the equivalent to HybridHttpOrThreadLocalScoped when there are no HttpSessionState instance.
Thank you.
EDIT
-to rearrange the question...
In general you should favor Nested Containers for lifecycle management. The reasons behind this are exactly what you've just noted, that in some situations using either Thread, HTTP, or hybrid scoped simply doesn't work. I've seen it cause huge issues before where people assume DB connections are being disposed because they are in other environments, but in one environment they aren't. Also, the explicitness is nice.
To do this set the dependencies you want disposed per request to Transient (the default) and dispose of the nested container at the end of the request. I've written about this workflow in webapi here. Additionally the official docs recommend this nuget.
For the console app you'll want to do something like this:
//parent Container set up at app start
public void On_UserAction()
{
//global container set up at app start, either use ObjectFactory (bad, deprecated and to be removed) or just keep track of it yourself.
using(var nestedContainer = GlobalContainer.GetNestedContainer())
{
var dependency = nestedContainer.GetInstance<DependencyThatHandlesUserInput>();
}
}
and that's it, the using block handles all the disposal for you.
If you have any other questions please ask, I've spent a lot of time on this sort of thing :).