How do I configure Flow to require type annotations for function parameters?
Specifically, I'd like Flow to show an error in the following code because params is not typed:
Types are inferred from usage. If this is an exported function then I recommend you use the types-first mode if you haven't already which enforces all module boundaries to have their types defined.
https://medium.com/flow-type/types-first-a-scalable-new-architecture-for-flow-3d8c7ba1d4eb
export function findOne(param) {
}
This will now throw an error and you must define the types of your function in your codebase.
You can achieve this by using eslint-plugin-flowtype and configuring require-parameter-type rule
Requires that all function parameters have type annotations
Related
Is it generally possible to use container parameters in method/class annotations in Symfony 5.3+?
For example one of my action methods uses a #ParamConverter annotation using the FOSRest RequestBodyParamConverter:
class SomeController extends AbstractController {
/**
* #ParamConverter("post", converter="fos_rest.request_body")
*/
public function sync(Request $request, Post $post): Response {
...
}
}
Instead of explicitly specifying the the converter here, I would like to use a container parameter instead. However, this does not seem to work.
I have checked that the parameter is defined correctly:
$ php bin/console debug:container --parameters
...
my.post.converter fos_rest.request_body
But I cannot use it:
/**
* #ParamConverter("post", converter="%my.post.converter%")
*/
No converter named '%my.post.converter%' found for conversion of
parameter 'post'.
I found other questions which indicate, that using parameters should be possible. At least when working with other annotations like #Route.
Is this a limitation of the #ParamConverter annotation (= a special feature of the #Route annotation), or is there anything wrong with my setup?
I know that there are other ways of specifying a different converter in this example. However, this is just an example and the question is, whether using a parameter here should be possible or if I made some error.
Not all annotations are equal. Each has its own processor, and each annotation argument has different accepted inputs.
And the annotations simply enable some underlying component, so sometimes (probably most of the time) if you can use a container parameter in an annotation, it's because the underlying component supports using a container parameter for that argument (as is the case with the Routing component, that can be configured via other ways than annotations/attributes)
Using a container parameter on the question provided example would not be particularly useful, if at all.
That argument expects a service ID, and since those IDs are defined on the container configuration (the same place where you would configure the parameters), moving the definition to a parameter would gain one nothing.
If you want to have it "configurable", maybe use a custom service id that you could define as an alias to the real service, that way you can have multiple converters and alias the correct one via configuration.
Not convinced that that would be something useful in real life, but your application constraints might be altogether different.
I have project, with some custom ConstraintValidator. I wanted to build custom message. I did so and everyting works just fine. Then we met need to have 'api' module, which means, that you have to split bean validation annotation and ConstraintValidator, have to use #Constraint(validatedBy = {}) and setup pairing manually using ConstraintMapping. Everyting stil works, except for message interpolation.
Log now contains kinda cryptic message:
Expression variables have been defined for constraint interface whatever.SomeValidation while Expression Language is not enabled.
All of that while I'm literary using the same code as one mentioned here:
https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_custom_contexts
to disableDefaultConstraintViolation and register custom one.
Any ideas what can cause that?
I'm trying to build a better Flowtype definition for Koa library and am kinda stuck.
My idea was to use Generic types to be able to specify customized Context class to Koa, so we can actually typecheck additional fields (populated by middlewares) instead of treating them as any.
so, I have:
declare type Context {…}
declare class Application<T: Context<T>> extends events$EventEmitter {
context: T,
…
}
fine…
but Context has a back-reference to Application, which is a generic dependent on Context. How do I spell this in typelib?
This doesn't look right, as I actually want to use not original Context but the type which was actually used by user
declare type Context {
app: Application<Context>
}
I just spent some time troubleshooting an aspect of Spring MVC's default handler method parameter resolution and I'd like to ask those closer to the project if this behavior is intended or if it'd be reasonable to open a ticket suggesting a change.
The issue has to do with the default resolution of POJO-style objects in method parameters like this:
#RequestMapping("/endpointwithparams")
public String endpointWithParams(EndpointParams params) {
// Do some stuff
return "viewname";
}
With no annotations or custom argument resolvers, Spring will attempt to bind the EndpointParams object by matching request parameters to its field names. It will even run validators if any are configured. This seems great - it lets me write simple POJO objects to organize related sets of parameters without having to have a custom argument resolver for each one.
The part that throws me off is that after the EndpointParams object is created it will also be automatically added to the model. This is because the actual resolver of this parameter will be a ModelAttributeMethodProcessor with its "annotationNotRequired" flag set to true. I don't want this parameter added to the model - its presence causes some trouble down the line - and it certainly wasn't intuitive to me that I should expect that addition to happen for a parameter that wasn't annotated with #ModelAttribute.
This behavior is also inconsistent with what happens when you have a "simple" request parameter like this:
#RequestMapping("/endpointwithparams")
public String endpointWithParams(String param) {
// Do some stuff
return "viewname";
}
In the above example, the String param will be resolved by the RequestParamMethodArgumentResolver, which will not add anything to the model.
Would it be reasonable to suggest that better default logic for non-annotated POJO parameters would be the same binding and validation that currently occurs, but without the automatic addition to the model? Or is there some context I'm missing that makes the full #ModelAttribute behavior the best default choice?
I am creating a command to generate accounts from a file. In command I have passed some arguments.
$this
->setName('batch:create')
->setDescription('xyz')
->setHelp('xyz')
->addArgument('account-id', InputArgument::REQUIRED, "Set the account id.")
->addArgument('name', InputArgument::REQUIRED, "Set the account name.");
I was just thinking if there is any way I can check type of argument passed. For now I am checking it like this,
if (is_numeric($input->getArgument('account-id'))) {
// ....
}
Is there anyway I can create a validator that checks the type and I just have to call validate function.
if ($input->validate() === false) {
// show error message and return.
}
Unfortunately, currently there's no way to implement command argument validation in Symfony. The best way to implement these checks would be overriding Symfony\Component\Console\Command::initialize method in your command and then applying the validation rules there, throwing exceptions if passed arguments are invalid.
Update: Matthias Noback has implemented symfony-console-form (https://github.com/matthiasnoback/symfony-console-form), and looks like implementing Matthias\SymfonyConsoleForm\Console\Command\FormBasedCommand interface would give you basic validation abilities through the form component (have to test it with validation, though).