RC0: TypeScript 'private' vs. 'public' keyword


#9

I’m pretty sure this issue will be tackled at some point. But until then I’d like to disable AoT


#10

Perhaps I have not yet banged into the teeth of this issue, but I have an app using the private members in the way I described upthread which seems to be working OK with the output of ionic build.


#11

So you’re saying that the AoT compiler is not smart enough to do a search/replace of private to public? And now instead we have to break a well established programming paradigm instead?

As they would say in Monty Python: That is very silly


#12

same problematic for protected?


#13

According to pkozlowski-opensource’s comment in this SO thread, this issue only applies to properties that are accessed from templates. That seems intuitive to me, but I’m wary of contradicting @mhartington.


#14

Yeah, sorry I should have been a bit more clear in thing. The way Pawel describes it is much better.

So if it needs to be accessible to the template, it needs to be public.

We recommend just using public to avoid edge cases. Plus, outside of Typescript, public/private don’t really have any meaning.

@larssn in regards to AoT being “smart enough”, the compiler only knows what you tell it, like every other compiler. If you tell it to not too look at module A, but then require module A later on…well how is it supposed to know what to do?


#15

Yeah but we’re talking about access modifiers. If the rule is: “private modifiers must not exist”, then clearly just deleting all private modifers prior to compiling isn’t some ridiculous notion? :slight_smile:

And access modifiers are valuable in how to help guide in using API’s and interfaces. I don’t want the interface of all my classes to be public, as certain methods might be for internal use only. I want my API’s to be simple and easy to understand, and access modifiers help in that aspect.


#16

Again…read the description…

Because the template becomes a class itself, anything that it needs to access need to be public. If you want to keep a private method that is only used internally to that component, go for it, keep it private. But if for some reason it needs to be exposed to the template(Class), it needs to be public.


#17

Not to beat a dead horse, but this is an important distinction to make, so that the entire concept of encapsulation isn’t lost in Typescript. Yes, it may only be a “compile-time” restriction, but it’s there so that we can take advantage of encapsulation in a declarative way; it’s a very nice feature :slight_smile: Glad to hear that we don’t have to expose everything everywhere though; template only exposure makes sense.

Thanks for the clarification!


#18

Hey Mike! Here’s a PR for making the migration steps clearer: https://github.com/driftyco/ionic/pull/8364


#19

I think TypeScript should have compiled the private variables in a different way.

class Greeter {
    private greeting: string;
    constructor(message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}

should be compiled to

var Greeter = (function () {
    function Greeter(message) {
        this.___greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.___greeting;
    };
    return Greeter;
}());

So any access to greeting member will fail in js .


#20

Only member functions and variables that are used in the HTML template need to be made public. The rest can remain private. You also must make any variables declared via @Input or @Output or @ViewChild public. The good news is that if you forget to make any of these public, when you run npm run build in the home directory of a project based on a stock project started with ionic start --v2 then you will get a compiler complaint about the variable being private and you can change those one by one until all your complaints go away.


Cannot find main.js ios build
#21

Didn’t know that compiler will complain. I was just blindly converting everything to public. Now I’ll keep everything private and convert to public whatever complier says.


#22

That makes a whole lot of sense, and makes the entire thing a lot more intuitive; thanks for clearing it up, once and for all.


#23

This is related.


#24

I don’t think _http needs to be public. I declared it as private in my app and works fine with RC1. The code compiled and working fine.
Or may be I missing something in my own code :slight_smile: and here as well.


#25

Hi all sorry to bring this old topic up again. Just to be clear in all my constructors the variables are set as private. Currently I do not have any errors as I am not accessing any of them through the template. What is the best practice for Ionic? That is convert them all to public or only to public where it is needed?

Also if I changed them to public will it have any effect on performance etc? Thanks just looking for the clarification on best practice here.


#26

The only ones that need to be public are those accessed in templates. There is zero effect on performance: access control is purely a build-time concept. At runtime it doesn’t exist at all.


#27

Are these templates as in ionic start blah [template-name]?


#28

Template as in the .html file for a given page/view.