[feature request] instanceof in an angular expression

1,864 views
Skip to first unread message

Matthew Handley

unread,
Aug 10, 2011, 6:35:43 PM8/10/11
to ang...@googlegroups.com
I would like to show and hide views when a particular object is an instanceof some 'class'. I can't seem to hack it into the parser to get this to work. Could this be a supported feature?

Matt

Witold Szczerba

unread,
Aug 10, 2011, 7:30:15 PM8/10/11
to ang...@googlegroups.com
Why won't you put that "instanceof" logic into controller and call
controller's method to get an answer?
Keep view simple, let the decisions happen in controllers.

Regards,
Witold Szczerba

> --
> You received this message because you are subscribed to the Google Groups
> "angular" group.
> To post to this group, send email to ang...@googlegroups.com.
> To unsubscribe from this group, send email to
> angular+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/angular?hl=en.
>

Matthew Handley

unread,
Aug 11, 2011, 8:37:13 AM8/11/11
to ang...@googlegroups.com
I suppose I could write a method called isBlahType(obj) which takes an object and returns true if it is of blah type, but that seems like a lot of boilerplate.

Matt

Witold Szczerba

unread,
Aug 11, 2011, 11:32:16 AM8/11/11
to ang...@googlegroups.com
It is not the point to get around the problem by literally moving code
to controller. It is about encapsulating logic inside controllers and
keeping low level abstractions hidden from the view. Creating a method
named isBlahTypeOf(someObject) and using it in view does not make your
view more transparent.

One of the best way to achieve this would be to start "coding" from
the view side. So at the beginning you have nothing but markup and you
adapt that markup to angular's widgets, directives, filters etc.... At
this point you are discovering requirements of the view. What
questions does your view have to ask controllers in order to render
itself.
Once view is done you start implementing the controllers. You do not
have to think about what methods you require, because you have already
discovered requirements, so you can focus on implementing. Then you go
lower and lower down to the deepest back-end.

Doing stuff that way keeps your code clean and simple, because all the
time you either implement or discover requirements, but never you have
to do those task at the same time.

I wrote the above just to explain my point of view better - I am not
referencing your particular case here.

Regards,
Witold Szczerba

Igor Minar

unread,
Aug 12, 2011, 8:31:26 PM8/12/11
to ang...@googlegroups.com
nicely said :-)

We are definitely trying to keep angular expressions simple and in fact we feel that currently they are already more powerful than what they should be. for example the assignment operator is a big source of evil (modifying the model from the view puts logic into the view that is hard to test and hard to maintain) and we are aiming our api-cleaning shotgun at it.

/i

Matthew Handley

unread,
Aug 12, 2011, 9:04:08 PM8/12/11
to ang...@googlegroups.com
I mean, my alternative is to create a state variable on the model that says which view to use, assign a unique identifier to each model-class that needs to have the specific view, and then switch on that type, but I had figured that using the built-in type information would be simpler, hence the request for instanceof.

Matt

Tim Cunningham

unread,
Aug 12, 2011, 9:12:18 PM8/12/11
to ang...@googlegroups.com
Sounds like you have tight coupling between your model and your view.  Is that really what you want?

Sent from my iPhone

Matthew Handley

unread,
Aug 12, 2011, 9:17:49 PM8/12/11
to ang...@googlegroups.com
I think so: The model contains a variable called selected_area that can be any one of three different kinds of Objects, depending on the mode the user is in. In each of these modes, a detail view provides more specific information about the selected_area. As far as I can tell, using something like instanceof in a ng:show expression would be the simplest way to toggle between these various views when the selected_area model object changes.

Matt

Igor Minar

unread,
Aug 13, 2011, 12:05:19 AM8/13/11
to ang...@googlegroups.com
ng:switch and a single controller method typeOf(model) should do the trick too without mocking with the parser.

/i

Alex Navis

unread,
Dec 5, 2012, 6:03:12 AM12/5/12
to ang...@googlegroups.com
I have a problem with using ng-show/ng-switch on a method. Whenever a method is bound to ng-switch/ng-show, the method becomes a listener at a global level across the application. Any change in any part of the UI, this function used in ng-show/ng-switch will be called.

This creates a lot of unnessary calls if we do ng-switch on a list of objects in UI.

Any suggestions on this. ?

Thanks,
Alex
Reply all
Reply to author
Forward
0 new messages