I know that in the constructor I load some dependencies as plugins or load providers that I will use in the class. but I do not know what should go inside the brackets? in some cases it is empty, but in others, variables are defined. What is the best practice and when it is agreed within these brackets, what should be included?
constructor(
public navCtrl: NavController // for example
){
????
}
So in general constructor is used during class instantiation and it is considered to be a good spot to initialize values of properties of the class. You can search SO for similar questions (difference between constructor and lifecycle hooks etc).
the way I adopted it was:
#Component({
selector: 'my-component',
template: `<div></div>`
})
export class SomeComponentWithForm {
// here you declare and type class properties/variables:
var: type
constructor(
// here you do dependency injection:
){
// here you initialize class' properties values:
this.var = value
}
ionViewDidLoad() {
// here your perform activities on first load of the component
}
other lifecycle hooks
}
Related
So my app has this component.js:
import Component from '#ember/component';
import layout from './template';
export default class MyComponent extends Component {
layout = layout;
init() {
this._super(...arguments);
}
}
When the component is rendered I am getting this error in the chrome console:
Assertion Failed: You must call `this._super(...arguments);` when overriding `init` on a framework object. Please update <savings-toolkit#component:my-component::ember2445> to call `this._super(...arguments);` from `init`.
The content is not loaded. I wish I could say more, but seriously, what the heck?
Yes, it was initially more much content when I started. It is, however, at this time, literally nothing more than the above.
No one's answering, but I found the answer.
If you are using classes, ie export default class myComponent extends Component as opposed to the old way (export default Component.extend) you shouldn't use this._super. Instead, you use the super keyword:
super.init(...arguments);
Mocking out dependencies while testing angular components. ComponentA injects ServiceA, I want to mock serviceA in my test
class ServiceA {
private _prop = 1;
get prop (): number {
return this._prop;
}
set prop(p: number) {
this._prop;
}
}
class ComponentA {
private injectedService: ServiceA;
constructor(private injectedService: ServiceA) {
this.injectedService = injectedService;
}
method () {
this.injectedService.prop = this.injectedService.prop + 1;
if (this.injectedService.prop === 5) {
this.injectedService.prop = 1;
}
}
}
With the above program structure it is important to have a serviceA mock that has accessor(getter and setter for injectedService.prop) implementation, since a part of the program is dependent on the value of injectedService.prop that was prior set.
Options that I have tried:
ts-mockito: ts-mockito mocks does not have access type set. With this limitation ts setter won't be recognised. A workaround would be to define actual methods to 'set' and 'get' and call these methods. setter would still need a more workaround as below:
// default get stub
when(mock.getProp()).thenReturn();
// setter redefines get stub
when(mock.setProp(anything())).thenCall((p) => {
when(mock.getProp()).thenReturn(a);
});
typemoq:
static mock calls constructor, big flaw when target mock class as other dependency injection(s)
dynamic mock conditions like (this.injectedService.prop === 5) will never be truthy beacuse this.injectedService.prop (i.e mock.object.prop) points to a function. On this I feel there could be a way that I'm yet to figure out, I would appreciate any help
(Personal preference) I prefer jasmine spyOn to typemoq verify for assertions on my mocks. This could be ignored if not possible.
Things I don't want to do
I do not want to modify classes to be mocked except to add standard typescript accessors
I do not want to create an Interface/Class off classes to be mocked just for the purpose of creating a mock for test
Although I'm open to compromise on above if there is a good justification or standard
I would also appreciate if anybody could direct me to code base(s) that has proper test and follows standard if any.
Note: I'm testing an angular app with karma + jasmine ... but all these doesn't count as I am merely creating class from constructor, no Testbed just simple typescript class unit-test.
Edit 1: it seems like I didn't explain myself very well. Class Foo is not an entity. Just a general purpose model that I would like to have an access to the entity manager.
Edit 2: I don't think there is an answer to my question. Basically, I wanted a class that can have access to the EntityManager without this class being called by the service manager, simply due to the fact that it may be called by a class who is also not called by the service manager. In other words, I was trying to achieve what Zend_Registry used to achieve in ZF1. I'll have to find another way of doing what I am trying to do.
I am trying to access Doctrine's entity manager in a model, in a similar way as it done in a controller:
$this->getServiceLocator()->get('Doctrine\ORM\EntityManager');
The ZF2 manual (http://framework.zend.com/manual/2.0/en/modules/zend.service-manager.quick-start.html) says:
By default, the Zend Framework MVC registers an initializer that will inject the ServiceManager instance, which is an implementation of Zend\ServiceManager\ServiceLocatorInterface, into any class implementing Zend\ServiceManager\ServiceLocatorAwareInterface.
So I created a the following class:
<?php
namespace MyModule\Model;
use Zend\ServiceManager\ServiceLocatorAwareInterface;
use Zend\ServiceManager\ServiceLocatorInterface;
class Foo implements ServiceLocatorAwareInterface
{
protected $services;
public function setServiceLocator(ServiceLocatorInterface $serviceLocator)
{
$this->services = $serviceLocator;
}
public function getServiceLocator()
{
return $this->services;
}
public function test()
{
$em = $this->getServiceLocator()->get('Doctrine\ORM\EntityManager');
}
}
Then, from another class I call this class as such:
$foo = new \MyModule\Model\Foo();
$foo->test()
which throws the following error:
PHP Fatal error: Call to a member function get() on a non-object
So, I guess I am missing something somewhere, but what? Where? How? Perhaps there is an easier to access the entity manager?
Thanks!
From your question, I see that you have mainly two misunderstandings, one about your design strategy (injecting an EntityManager on your model) and one about how things work with the service manager (ServiceLocatorAwareInterface). In my answer I'll try to focus on the second one.
Initializers are php closures that are called over each instance accessed from the Service Manager before this one returns it to you.
Here is an example of an Initializer :
// Line 146 - 150 of Zend\Mvc\Service\ServiceManagerConfig class + comments
$serviceManager->addInitializer(function ($instance) use ($serviceManager) {
if ($instance instanceof ServiceManagerAwareInterface) {
$instance->setServiceManager($serviceManager);
}
});
As you can see each time Service Manager is asked to return an instance/object that implements the ServiceManagerAwareInterface interface, it will setup/inject the Service Manager instance to it.
By the way in your previous code you omitted to implement correctly the interface as you didn't define the setServiceManager method. However, this is not your only problem.
First, if you want the Service Manager to inject itself in your Model, you need to call/construct your model instance from it (during this process it will call the initializers) through a factory for example if your class has complex dependencies.
[EDIT]
Example:
In your MyModule
namespace MyModule;
use Zend\ModuleManager\Feature\ServiceProviderInterface;
use MyModule\Model\Foo;
class Module implements ServiceProviderInterface{
//Previous code
public function getServiceConfig()
{
return array(
'instances' => array(
'myModelClass' => new Foo(),
),
);
}
Now, when you need a Foo instance you should call the Service Manager:
$serviceManager->get('myModelClass');
Don't forget defining setServiceManager method, otherwise your'e not correctly implementing the ServiceManagerAwareInterface!
I think, the only thing you’re missing, is to add your model class to the list of invokables and retreive it through the service manager.
So basically add this to your module.conf.php:
return array(
'service_manager' => array(
'invokables' => array(
'MyModule\Model\Foo' => 'MyModule\Model\Foo',
),
),
);
And instantiate your model object like this (if in a controller):
$foo = $this->getServiceLocator()->get('MyModule\Model\Foo');
$foo->test();
I have started making TypeScript definitions for the Ember.js framework. I have currently set it up structured like this:
declare module Ember {
interface Classname {
someProperty: type;
}
declare var Classname: Classname;
}
In order to access these interfaces I declare a variable. However in my library there is a classname called Object, this causes a nameclash with the Object from the global scope.
How do I surpass this nameclash? And am I using the right practise for creating definitions for an existing library?
You might want to grab the EmberJS definition file from GitHub:
https://github.com/borisyankov/DefinitelyTyped/blob/master/ember/ember-1.0.d.ts
This not only solves your problem as it has the Ember definition, but you can also see how they achieved it in spite of name clashes:
declare module Ember {
export class Object extends CoreObject {
//...
This makes Object a child of Ember, rather than of window:
Ember.Object
Rather than
window.Object
// or the shorthand
Object // which is window.Object
I came across at this thread, does anybody know how to do this in Play! 1.2.4? Thanks.
The same effect is not quite possible, I think. You can of course reference classes in your Models package by using fully qualified names (models.YourModel) to access enumerations, for example.
Anything you add in the renderArgs scope in your controller will be available in the template, plus there are some implicit objects that are always in use (see Play framework documentation for full listing). For example the play.Play object contains all kinds of useful stuff.
With #Before and #With annotations you can set up a controller used by multiple other controllers to have objects "globally" available - see Interceptions.
Even better, create a super controller extending Controller. Afterwards, let all your controllers extends your SuperController.
class SuperController extends Controller {
#Before
public static function before() {
// Set global variables using renderArgs
}
}
class MyController extends SuperController {
public function myMethod() {
// Do whatever your method does.
}
}
Check out the documentation : http://www.playframework.org/documentation/1.2.4/controllers#result