The formik documentation seems to discourage use of the useFormik hook - but the entire Getting Started tutorial exclusively uses useFormik - so I'm not sure how to proceed - it's very confusing. Is there a downside of using useFormik if I don't need connect, FastField, ErrorMessage, etc.
I don't think it discourages you to use useFormik, but in most of the use cases it's not necessary, as you won't get any perks of using context api. Field, FieldArray, etc uses formik context internally so you won't be able to use these components. But in my opinion by using this useFormik hook you'll be creating more of your own implementation for these kind of components. But it doesn't hurt to learn that as well as internals of Formik are based on this hook.
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/
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.
I'm new to Laravel & I wanted to know something about it's feature that calls Contracts.
(If my question not in place, let me know why, and don't just downvote it).
So from what I red in Laravel Documentation and say on Laracasts videos, I understood that contracts they are only interfaces for class implementation.
So what it's good for? That if I or someone else will implement those interfaces will all need to go by the interface and then I dont need to change my code at all?
Is that the reason why Laravel uses it's implementation as a contracts ?
Also I wanted to know, to achive the implementation I must bind the implementation to a contract?
Yes, I think your understanding is mostly correct. I will try to explain with an example. Let's say you have a PackageDeliveryServiceContract that has some methods like trackPackage, getShippingCost.
You create a FedexDeliveryService to adhere to the contract and implement those methods.
In your controller, you can just inject PackageDeliveryServiceContract and start using it right away. (are you familiar with laravel's dependency injection?).
Let's say later you decide you no longer want to ship with Fedex and use UPS instead. Then you can create UPSDeliveryService that also adheres to that contract.
Now, all you need to do is change your binding from FedexDeliveryService to UPSDeliveryService and you don't need to make any changes to your controller code.
Typically you will create the binding between contract and implementation inside a service provider such as app/Providers/AppServiceProvider.php
What is the suggested way to implement output caching of service responses when using http://razor.servicestack.net?
Not used it since it's 4.5 and our current projects are 4.0, but perhaps CacheStack may be of use?
Otherwise handle it yourself via wrapping existing services with the ToOptimizedResultUsingCache extension method, and manually expiring cache keys on CRUD type operations.
What is the best approach to version WebAPIs?
I am building an API from scratch and I would like to ensure that it will version gracefully in the future. I am envisioning something like mysite.com/api/v2/...
One approach I see is to create a separate project (web app) for each version of API. But perhaps there are better ways to do it?
Thank you for your ideas.
Including version number in the URL is the standard approach as I explained in this post (I do not repeat the content): Implementing versioning a RESTful API with WCF or ASP.Net Web Api
You do not need to create a completely new project although you can. The problem that you will be facing with a single project is that there will be collision of names:
/api/v1.0/Car/123
and
/api/v2.0/Car/123
both will point to CarController while you can have only one of those. The solution would be to implement your own IHttpControllerSelector and register with the DependencyResolver. This implementation will look at the version number and perhaps find the type based on the namespace.
UPDATE
I do not intend to start a REST controversy here. But as #DarrelMiller points out, here is an older discussion on the same subject discouraging my suggested approach:
How to version REST URIs
I personally think URL versioning is the way to go.
You will need to create your own implementation of IHttpControllerSelector. The best way is to base this implementation on Microsoft's IHttpControllerSelector. Then you can decide in your IHttpControllerSelectorif you want to version by URL or by content-type.
The most basic implementation directly implements IHttpControllerSelector and just implements the SelectController method but performance reasons it is better to implement some caching around it.
For finding the Controller you simple the IHttpControllerTypeResolver instance you can get using HttpConfiguration.Services.
I've used something like this: http://damsteen.nl/blog/implementing-versioning-in-asp.net-web-api. Also put some code on Github: https://github.com/Sebazzz/SDammann.WebApi.Versioning.