{"id":1324,"date":"2023-08-16T05:00:00","date_gmt":"2023-08-16T12:00:00","guid":{"rendered":"https:\/\/www.angulartraining.com\/daily-newsletter\/?p=1324"},"modified":"2023-08-15T16:44:52","modified_gmt":"2023-08-15T23:44:52","slug":"best-practices-for-using-visibility-modifiers","status":"publish","type":"post","link":"https:\/\/www.angulartraining.com\/daily-newsletter\/best-practices-for-using-visibility-modifiers\/","title":{"rendered":"Best practices for using visibility modifiers"},"content":{"rendered":"\n

Yesterday, we talked about Typescript visibility modifiers<\/a> in the context of Angular classes. Today, I want to focus on best practices and common scenarios that involve such visibility modifiers. <\/p>\n\n\n\n

First, it’s very common to have Angular services that use RxJs Subjects<\/a>. Subjects are somewhat dangerous because they can be used to emit data to all subscribers. As a result, it makes sense to “hide” a subject by making it private and then expose an Observable out of it as follows:<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

Note that we don’t need to make data$<\/code> public, because any field that isn’t private<\/code> or protected<\/code> is public<\/code> by default. Using readonly<\/code> enforces that other components\/services cannot assign a new value to data$<\/code>. As a result, the above code is safe: The business logic that decides when and how to emit data is “hidden” in our service (where it belongs), and yet the rest of the application can be notified when the data changes without being able to break that process by accident.<\/p>\n\n\n\n

Of course, the same idea applies to Signals (see my best practices for Signals<\/a>)<\/p>\n\n\n\n

Another option suggested in that post is to define a getter method that returns the read-only object:<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

This is equivalent to using readonly<\/code>. The value can’t be changed because we define a getter and no setter.<\/p>\n\n\n\n

Let’s complete our best practices list from yesterday:<\/p>\n\n\n\n

    \n
  1. Make every member private<\/code> by default<\/li>\n\n\n\n
  2. If the member is needed in the template of a component, make it protected<\/code><\/li>\n\n\n\n
  3. If the member is meant to be fully public, go with public<\/code><\/li>\n\n\n\n
  4. If the member should be accessible but not modifiable, use readonly<\/code> or a single getter with no setter<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    Yesterday, we talked about Typescript visibility modifiers in the context of Angular classes. Today, I want to focus on best practices and common scenarios that involve such visibility modifiers. First, it’s very common to have Angular services that use RxJs Subjects. Subjects are somewhat dangerous because they can be used to emit data to all […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,31,3],"tags":[],"class_list":["post-1324","post","type-post","status-publish","format-standard","hentry","category-angular","category-best-practices","category-typescript"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t