Nat  Grady

Nat Grady

1677846480

Render.rs: A Safe & Simple Template Engine with The Ergonomics Of JSX

Render

🔏 A safe and simple template engine with the ergonomics of JSX

render itself is a combination of traits, structs and macros that together unify and boost the experience of composing tree-shaped data structures. This works best with HTML and XML rendering, but can work with other usages as well, like ReasonML's Pastel library for terminal colors.

How?

A renderable component is a struct that implements the Render trait. There are multiple macros that provide a better experience implementing Renderable:

  • #[component] for defining components using a function
  • rsx! for composing elements with JSX ergonomics
  • html! for composing elements and render them to a string

Why is this different from...

handlebars?

Handlebars is an awesome spec that lets us devs define templates and work seemlessly between languages and frameworks. Unfortunately, it does not guarantee any of Rust's type-safety, due to its spec. This forces you to write tests for validating types for your views, like you would in a dynamically typed language. These tests weren't necessary in a type-safe language like Rust — but Handlebars is JSON-oriented, which doesn't comply Rust's type system.

render provides the same level of type-safety Rust provides, with no compromises of ergonomics or speed.

typed-html?

typed-html is a wonderful library. Unfortunately, it focused its power in strictness of the HTML spec itself, and doesn't allow arbitrary compositions of custom elements.

render takes a different approach. For now, HTML is not typed at all. It can get any key and get any string value. The main focus is custom components, so you can create a composable and declarative template with no runtime errors.

Usage

Simple HTML rendering

In order to render a simple HTML fragment into a String, use the rsx! macro to generate a component tree, and call render on it:

use render::{rsx, Render};

let tree = rsx! {
  <div>
    <h1>{"Hello!"}</h1>
    <p>{"Hello world!"}</p>
  </div>
};

assert_eq!(tree.render(), "<div><h1>Hello!</h1><p>Hello world!</p></div>");

Because this is so common, there's another macro called html! that calls rsx! to generate a component tree, and then calls render on it. Most of the time, you'll find yourself using the rsx! macro to compose arbitrary components, and only calling html! when you need a String output, when sending a response or generating a Markdown file.

In Render, attributes and plain strings are escaped using the render::html_escaping module. In order to use un-escaped values so you can dangerously insert raw HTML, use the raw! macro around your string:

use render::{html, raw};

let tree = html! {
  <div>
    <p>{"<Hello />"}</p>
    <p>{raw!("<Hello />")}</p>
  </div>
};

assert_eq!(tree, "<div><p>&lt;Hello /&gt;</p><p><Hello /></p></div>");

Custom components

Render's greatest ability is to provide type-safety along with custom renderable components. Introducing new components is as easy as defining a function that returns a Render value.

In order to build up components from other components or HTML nodes, you can use the rsx! macro, which generates a Render component tree:

use render::{component, rsx, html};

#[component]
fn Heading<'title>(title: &'title str) {
  rsx! { <h1 class={"title"}>{title}</h1> }
}

let rendered_html = html! {
  <Heading title={"Hello world!"} />
};

assert_eq!(rendered_html, r#"<h1 class="title">Hello world!</h1>"#);

If you pay close attention, you see that the function Heading is:

  • declared with an uppercase. Underneath, it generates a struct with the same name, and implements the Render trait on it.
  • does not have a return type. This is because everything is written to a writer, for performance reasons.

Visibility & Component Libraries

Often you're going to want to store your components somewhere else in your project tree other than the module you're working on (if not in a different module entirely!). In these cases, the visibility applied top the function that defines your component will flow down into all fields of that struct.

For example, if we add "pub" to the front of our Heading component above:

#[component]
pub fn Heading<'title>(title: &'title str) {
  rsx! { <h1 class={"title"}>{title}</h1> }
}

...the struct that is generated would look something like...

pub struct Heading {
  pub title: &'title str
}

This is important to understand from a safety point of view when structuring your libraries.

Full example

// A simple HTML 5 doctype declaration
use render::html::HTML5Doctype;
use render::{
    // A macro to create components
    component,
    // A macro to compose components in JSX fashion
    rsx,
    // A macro to render components in JSX fashion
    html,
    // A trait for custom components
    Render,
};

// This can be any layout we want
#[component]
fn Page<'a, Children: Render>(title: &'a str, children: Children) {
   rsx! {
     <>
       <HTML5Doctype />
       <html>
         <head><title>{title}</title></head>
         <body>
           {children}
         </body>
       </html>
     </>
   }
}

// This can be a route in Rocket, the web framework,
// for instance.
pub fn some_page(user_name: &str) -> String {
    html! {
      <Page title={"Home"}>
        {format!("Welcome, {}", user_name)}
      </Page>
    }
}

Download Details:

Author: Render-rs
Source Code: https://github.com/render-rs/render.rs 
License: MIT license

#rust #html #template #component #jsx 

What is GEEK

Buddha Community

Render.rs: A Safe & Simple Template Engine with The Ergonomics Of JSX
Nat  Grady

Nat Grady

1677846480

Render.rs: A Safe & Simple Template Engine with The Ergonomics Of JSX

Render

🔏 A safe and simple template engine with the ergonomics of JSX

render itself is a combination of traits, structs and macros that together unify and boost the experience of composing tree-shaped data structures. This works best with HTML and XML rendering, but can work with other usages as well, like ReasonML's Pastel library for terminal colors.

How?

A renderable component is a struct that implements the Render trait. There are multiple macros that provide a better experience implementing Renderable:

  • #[component] for defining components using a function
  • rsx! for composing elements with JSX ergonomics
  • html! for composing elements and render them to a string

Why is this different from...

handlebars?

Handlebars is an awesome spec that lets us devs define templates and work seemlessly between languages and frameworks. Unfortunately, it does not guarantee any of Rust's type-safety, due to its spec. This forces you to write tests for validating types for your views, like you would in a dynamically typed language. These tests weren't necessary in a type-safe language like Rust — but Handlebars is JSON-oriented, which doesn't comply Rust's type system.

render provides the same level of type-safety Rust provides, with no compromises of ergonomics or speed.

typed-html?

typed-html is a wonderful library. Unfortunately, it focused its power in strictness of the HTML spec itself, and doesn't allow arbitrary compositions of custom elements.

render takes a different approach. For now, HTML is not typed at all. It can get any key and get any string value. The main focus is custom components, so you can create a composable and declarative template with no runtime errors.

Usage

Simple HTML rendering

In order to render a simple HTML fragment into a String, use the rsx! macro to generate a component tree, and call render on it:

use render::{rsx, Render};

let tree = rsx! {
  <div>
    <h1>{"Hello!"}</h1>
    <p>{"Hello world!"}</p>
  </div>
};

assert_eq!(tree.render(), "<div><h1>Hello!</h1><p>Hello world!</p></div>");

Because this is so common, there's another macro called html! that calls rsx! to generate a component tree, and then calls render on it. Most of the time, you'll find yourself using the rsx! macro to compose arbitrary components, and only calling html! when you need a String output, when sending a response or generating a Markdown file.

In Render, attributes and plain strings are escaped using the render::html_escaping module. In order to use un-escaped values so you can dangerously insert raw HTML, use the raw! macro around your string:

use render::{html, raw};

let tree = html! {
  <div>
    <p>{"<Hello />"}</p>
    <p>{raw!("<Hello />")}</p>
  </div>
};

assert_eq!(tree, "<div><p>&lt;Hello /&gt;</p><p><Hello /></p></div>");

Custom components

Render's greatest ability is to provide type-safety along with custom renderable components. Introducing new components is as easy as defining a function that returns a Render value.

In order to build up components from other components or HTML nodes, you can use the rsx! macro, which generates a Render component tree:

use render::{component, rsx, html};

#[component]
fn Heading<'title>(title: &'title str) {
  rsx! { <h1 class={"title"}>{title}</h1> }
}

let rendered_html = html! {
  <Heading title={"Hello world!"} />
};

assert_eq!(rendered_html, r#"<h1 class="title">Hello world!</h1>"#);

If you pay close attention, you see that the function Heading is:

  • declared with an uppercase. Underneath, it generates a struct with the same name, and implements the Render trait on it.
  • does not have a return type. This is because everything is written to a writer, for performance reasons.

Visibility & Component Libraries

Often you're going to want to store your components somewhere else in your project tree other than the module you're working on (if not in a different module entirely!). In these cases, the visibility applied top the function that defines your component will flow down into all fields of that struct.

For example, if we add "pub" to the front of our Heading component above:

#[component]
pub fn Heading<'title>(title: &'title str) {
  rsx! { <h1 class={"title"}>{title}</h1> }
}

...the struct that is generated would look something like...

pub struct Heading {
  pub title: &'title str
}

This is important to understand from a safety point of view when structuring your libraries.

Full example

// A simple HTML 5 doctype declaration
use render::html::HTML5Doctype;
use render::{
    // A macro to create components
    component,
    // A macro to compose components in JSX fashion
    rsx,
    // A macro to render components in JSX fashion
    html,
    // A trait for custom components
    Render,
};

// This can be any layout we want
#[component]
fn Page<'a, Children: Render>(title: &'a str, children: Children) {
   rsx! {
     <>
       <HTML5Doctype />
       <html>
         <head><title>{title}</title></head>
         <body>
           {children}
         </body>
       </html>
     </>
   }
}

// This can be a route in Rocket, the web framework,
// for instance.
pub fn some_page(user_name: &str) -> String {
    html! {
      <Page title={"Home"}>
        {format!("Welcome, {}", user_name)}
      </Page>
    }
}

Download Details:

Author: Render-rs
Source Code: https://github.com/render-rs/render.rs 
License: MIT license

#rust #html #template #component #jsx 

Beth  Cooper

Beth Cooper

1659694200

Easy Activity Tracking for Models, Similar to Github's Public Activity

PublicActivity

public_activity provides easy activity tracking for your ActiveRecord, Mongoid 3 and MongoMapper models in Rails 3 and 4.

Simply put: it can record what happens in your application and gives you the ability to present those recorded activities to users - in a similar way to how GitHub does it.

!! WARNING: README for unreleased version below. !!

You probably don't want to read the docs for this unreleased version 2.0.

For the stable 1.5.X readme see: https://github.com/chaps-io/public_activity/blob/1-5-stable/README.md

About

Here is a simple example showing what this gem is about:

Example usage

Tutorials

Screencast

Ryan Bates made a great screencast describing how to integrate Public Activity.

Tutorial

A great step-by-step guide on implementing activity feeds using public_activity by Ilya Bodrov.

Online demo

You can see an actual application using this gem here: http://public-activity-example.herokuapp.com/feed

The source code of the demo is hosted here: https://github.com/pokonski/activity_blog

Setup

Gem installation

You can install public_activity as you would any other gem:

gem install public_activity

or in your Gemfile:

gem 'public_activity'

Database setup

By default public_activity uses Active Record. If you want to use Mongoid or MongoMapper as your backend, create an initializer file in your Rails application with the corresponding code inside:

For Mongoid:

# config/initializers/public_activity.rb
PublicActivity.configure do |config|
  config.orm = :mongoid
end

For MongoMapper:

# config/initializers/public_activity.rb
PublicActivity.configure do |config|
  config.orm = :mongo_mapper
end

(ActiveRecord only) Create migration for activities and migrate the database (in your Rails project):

rails g public_activity:migration
rake db:migrate

Model configuration

Include PublicActivity::Model and add tracked to the model you want to keep track of:

For ActiveRecord:

class Article < ActiveRecord::Base
  include PublicActivity::Model
  tracked
end

For Mongoid:

class Article
  include Mongoid::Document
  include PublicActivity::Model
  tracked
end

For MongoMapper:

class Article
  include MongoMapper::Document
  include PublicActivity::Model
  tracked
end

And now, by default create/update/destroy activities are recorded in activities table. This is all you need to start recording activities for basic CRUD actions.

Optional: If you don't need #tracked but still want the comfort of #create_activity, you can include only the lightweight Common module instead of Model.

Custom activities

You can trigger custom activities by setting all your required parameters and triggering create_activity on the tracked model, like this:

@article.create_activity key: 'article.commented_on', owner: current_user

See this entry http://rubydoc.info/gems/public_activity/PublicActivity/Common:create_activity for more details.

Displaying activities

To display them you simply query the PublicActivity::Activity model:

# notifications_controller.rb
def index
  @activities = PublicActivity::Activity.all
end

And in your views:

<%= render_activities(@activities) %>

Note: render_activities is an alias for render_activity and does the same.

Layouts

You can also pass options to both activity#render and #render_activity methods, which are passed deeper to the internally used render_partial method. A useful example would be to render activities wrapped in layout, which shares common elements of an activity, like a timestamp, owner's avatar etc:

<%= render_activities(@activities, layout: :activity) %>

The activity will be wrapped with the app/views/layouts/_activity.html.erb layout, in the above example.

Important: please note that layouts for activities are also partials. Hence the _ prefix.

Locals

Sometimes, it's desirable to pass additional local variables to partials. It can be done this way:

<%= render_activity(@activity, locals: {friends: current_user.friends}) %>

Note: Before 1.4.0, one could pass variables directly to the options hash for #render_activity and access it from activity parameters. This functionality is retained in 1.4.0 and later, but the :locals method is preferred, since it prevents bugs from shadowing variables from activity parameters in the database.

Activity views

public_activity looks for views in app/views/public_activity.

For example, if you have an activity with :key set to "activity.user.changed_avatar", the gem will look for a partial in app/views/public_activity/user/_changed_avatar.html.(|erb|haml|slim|something_else).

Hint: the "activity." prefix in :key is completely optional and kept for backwards compatibility, you can skip it in new projects.

If you would like to fallback to a partial, you can utilize the fallback parameter to specify the path of a partial to use when one is missing:

<%= render_activity(@activity, fallback: 'default') %>

When used in this manner, if a partial with the specified :key cannot be located it will use the partial defined in the fallback instead. In the example above this would resolve to public_activity/_default.html.(|erb|haml|slim|something_else).

If a view file does not exist then ActionView::MisingTemplate will be raised. If you wish to fallback to the old behaviour and use an i18n based translation in this situation you can specify a :fallback parameter of text to fallback to this mechanism like such:

<%= render_activity(@activity, fallback: :text) %>

i18n

Translations are used by the #text method, to which you can pass additional options in form of a hash. #render method uses translations when view templates have not been provided. You can render pure i18n strings by passing {display: :i18n} to #render_activity or #render.

Translations should be put in your locale .yml files. To render pure strings from I18n Example structure:

activity:
  article:
    create: 'Article has been created'
    update: 'Someone has edited the article'
    destroy: 'Some user removed an article!'

This structure is valid for activities with keys "activity.article.create" or "article.create". As mentioned before, "activity." part of the key is optional.

Testing

For RSpec you can first disable public_activity and add require helper methods in the rails_helper.rb with:

#rails_helper.rb
require 'public_activity/testing'

PublicActivity.enabled = false

In your specs you can then blockwise decide whether to turn public_activity on or off.

# file_spec.rb
PublicActivity.with_tracking do
  # your test code goes here
end

PublicActivity.without_tracking do
  # your test code goes here
end

Documentation

For more documentation go here

Common examples

Set the Activity's owner to current_user by default

You can set up a default value for :owner by doing this:

  1. Include PublicActivity::StoreController in your ApplicationController like this:
class ApplicationController < ActionController::Base
  include PublicActivity::StoreController
end
  1. Use Proc in :owner attribute for tracked class method in your desired model. For example:
class Article < ActiveRecord::Base
  tracked owner: Proc.new{ |controller, model| controller.current_user }
end

Note: current_user applies to Devise, if you are using a different authentication gem or your own code, change the current_user to a method you use.

Disable tracking for a class or globally

If you need to disable tracking temporarily, for example in tests or db/seeds.rb then you can use PublicActivity.enabled= attribute like below:

# Disable p_a globally
PublicActivity.enabled = false

# Perform some operations that would normally be tracked by p_a:
Article.create(title: 'New article')

# Switch it back on
PublicActivity.enabled = true

You can also disable public_activity for a specific class:

# Disable p_a for Article class
Article.public_activity_off

# p_a will not do anything here:
@article = Article.create(title: 'New article')

# But will be enabled for other classes:
# (creation of the comment will be recorded if you are tracking the Comment class)
@article.comments.create(body: 'some comment!')

# Enable it again for Article:
Article.public_activity_on

Create custom activities

Besides standard, automatic activities created on CRUD actions on your model (deactivatable), you can post your own activities that can be triggered without modifying the tracked model. There are a few ways to do this, as PublicActivity gives three tiers of options to be set.

Instant options

Because every activity needs a key (otherwise: NoKeyProvided is raised), the shortest and minimal way to post an activity is:

@user.create_activity :mood_changed
# the key of the action will be user.mood_changed
@user.create_activity action: :mood_changed # this is exactly the same as above

Besides assigning your key (which is obvious from the code), it will take global options from User class (given in #tracked method during class definition) and overwrite them with instance options (set on @user by #activity method). You can read more about options and how PublicActivity inherits them for you here.

Note the action parameter builds the key like this: "#{model_name}.#{action}". You can read further on options for #create_activity here.

To provide more options, you can do:

@user.create_activity action: 'poke', parameters: {reason: 'bored'}, recipient: @friend, owner: current_user

In this example, we have provided all the things we could for a standard Activity.

Use custom fields on Activity

Besides the few fields that every Activity has (key, owner, recipient, trackable, parameters), you can also set custom fields. This could be very beneficial, as parameters are a serialized hash, which cannot be queried easily from the database. That being said, use custom fields when you know that you will set them very often and search by them (don't forget database indexes :) ).

Set owner and recipient based on associations

class Comment < ActiveRecord::Base
  include PublicActivity::Model
  tracked owner: :commenter, recipient: :commentee

  belongs_to :commenter, :class_name => "User"
  belongs_to :commentee, :class_name => "User"
end

Resolve parameters from a Symbol or Proc

class Post < ActiveRecord::Base
  include PublicActivity::Model
  tracked only: [:update], parameters: :tracked_values
  
  def tracked_values
   {}.tap do |hash|
     hash[:tags] = tags if tags_changed?
   end
  end
end

Setup

Skip this step if you are using ActiveRecord in Rails 4 or Mongoid

The first step is similar in every ORM available (except mongoid):

PublicActivity::Activity.class_eval do
  attr_accessible :custom_field
end

place this code under config/initializers/public_activity.rb, you have to create it first.

To be able to assign to that field, we need to move it to the mass assignment sanitizer's whitelist.

Migration

If you're using ActiveRecord, you will also need to provide a migration to add the actual field to the Activity. Taken from our tests:

class AddCustomFieldToActivities < ActiveRecord::Migration
  def change
    change_table :activities do |t|
      t.string :custom_field
    end
  end
end

Assigning custom fields

Assigning is done by the same methods that you use for normal parameters: #tracked, #create_activity. You can just pass the name of your custom variable and assign its value. Even better, you can pass it to #tracked to tell us how to harvest your data for custom fields so we can do that for you.

class Article < ActiveRecord::Base
  include PublicActivity::Model
  tracked custom_field: proc {|controller, model| controller.some_helper }
end

Help

If you need help with using public_activity please visit our discussion group and ask a question there:

https://groups.google.com/forum/?fromgroups#!forum/public-activity

Please do not ask general questions in the Github Issues.


Author: public-activity
Source code: https://github.com/public-activity/public_activity
License: MIT license

#ruby  #ruby-on-rails 

Nico Jonsson

Nico Jonsson

1605576444

How to Use DOM Manipulation properly in Angular

If you are coming from the background of working with angularjs, it was quite straight forward to access and manipulate the DOM there. You had access to the DOM node through element injected in the link function of the directive.

function link(scope, element, attrs) {
}

Or through angular.element which was an AngularJS’s built in subset of jQuery. But this approach had its drawbacks. It made your code tightly coupled with Browser’s API.

The new Angular (2 onwards) works on multiple platforms: mobile, web workers etc. So, they have introduced a number of APIs to work as an abstraction layer between your code and platform APIs. These APIs come in the form of different reference types likeElementRef, TemplateRef, ViewRef, ComponentRef and ViewContainerRef.

In this blog, we will see some examples of how these reference types can be used to manipulate DOM in angular. But before that let’s look at the ways to access these reference types within a Component/Directive.

DOM Queries

Angular has provided two ways to query/access various reference types within a Component/Directive. These are

  • ViewChild/ViewChildren
  • ContentChild/ContentChildren

ViewChild/ViewChildren

These are decorators which can be used within a Component/Directive as @ViewChild (returns a single reference) or @ViewChildren (returns a list of references in the form of a QueryList). These will assign the values of reference types from template to the component fields they are applied to. The basic usage is as follow:

@ViewChild(selector, {read: ReferenceType}) fieldName;

A selector can be a string representing a template reference variable, or a Component/Directive class, or a TemplateRef or a provider defined in the child component tree.

@ViewChild("myElem") template: ElementRef;

The second parameter is optional and is only required to query some reference types which can’t be inferred easily by Angular like ViewContainerRef.

@ViewChild("myContainer", {read: ViewContainerRef}) container: ViewContainerRef;

ContentChild/ContentChildren

The usage is pretty much similar to that of ViewChild/ViewChildren. The only difference is that it queries within the <ng-content> projected elements of the component while the @ViewChild queries within the template of the component. This will be explained better in the examples of upcoming sections.

DOM access via ElementRef

ElementRef is a very basic abstraction layer on a DOM element in Angular. It’s an angular wrapper around the native element.

You can get hold of ElementRef in a Component or Directive in following ways:

Dependency Injection

Host element of a Component or Directive can be accessed via direct DI in the constructor.

@Component({
  selector: 'app-test',
  template: '<div>I am a test component</div>'
})
export class TestComponent implements OnInit {

  constructor(private element: ElementRef) { }

  ngOnInit() {
    console.log(this.element.nativeElement);
  }

}
/*
* Output: 
*   <app-test>
*     <div>I am a test component</div>
*   </app-test>
* */

Using ViewChild and Template Reference Variables

@Component({
  selector: 'app-test',
  template: `
    <div #child1>First Child</div>
    <div>Second Child</div>
  `
})
export class TestComponent implements OnInit {

  @ViewChild("child1") firstChild: ElementRef;

  constructor() { }

  ngOnInit() {
    console.log(this.firstChild.nativeElement);
  }

}

/*
* Output: <div>First Child</div>
* */

Using ContentChild

Works in a similar manner as that of @ViewChild, but for <ng-content> projected elements.

// Child Component
@Component({
  selector: "component-a",
  template: `<ng-content></ng-content>`
})
export class ComponentA {
  @ContentChild("contentChild") contentChild: ElementRef;
  
  ngOnInit() {
    console.log(this.contentChild.nativeElement);
  }
}
// Parent Component
@Component({
  selector: 'app-test',
  template: `
    <component-a>
      <div #contentChild>Content Child 1</div>
      <div>Content Child 2</div>
    </component-a>
  `
})
export class TestComponent implements OnInit {}
/*
* Output: <div>Content Child 1</div>
* */

It looks pretty straight forward that you can easily access a DOM element via ElementRef and then manipulate the DOM by accessing the nativeElement. Something like this:

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body" #body>
    </div>
    <div class="footer">I am a footer</div>
  `
})
export class TestComponent implements AfterContentInit {
  @ViewChild("body") bodyElem: ElementRef;

  ngAfterContentInit(): void {
    this.bodyElem.nativeElement.innerHTML = `<div>Hi, I am child added by directly calling the native APIs.</div>`;
  }

}

However, the direct usage of ElementRef is discouraged by Angular Team because it directly provides the access to DOM which can make your application vulnerable to XSS attacks. It also creates tight coupling between your application and rendering layers which makes is difficult to run an app on multiple platforms.

Everything is a ‘View’ in Angular

A view is the smallest building block of an angular app’s UI. Every component has its own view. You can consider it as a group of elements which can be created and destroyed together.

A view can be classified into two types:

  • Embedded Views — created from templates
  • Host Views — created from components

Displaying a view in UI can be broken down into two steps:

  1. Creating a view from template or component
  2. Rendering a view into a view container

Embedded Views

Embedded views are created from templates defined using <ng-template> element.

Creating an embedded view

First a template needs to be accessed within a component as TemplateRefusing @ViewChild and template reference variable. Then, an embedded view can be created from a TemplateRef by passing a data-binding context.

const viewRef = this.template.createEmbeddedView({
  name: "View 1"
});

This context is being consumed by the template in<ng-template>.

<ng-template #template let-viewName="name">
  <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
</ng-template>

You can also use the $implicit property in the context if you have only a single property to bind.

const viewRef = this.template.createEmbeddedView({
  $implicit: "View 1"
});

In this case, you can skip assigning values to template variables.

<ng-template #template let-viewName>
  <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
</ng-template>

Rendering an embedded view

Till now, we have created only an instance of ViewRef. This view is still not visible in the UI. In order to see it in the UI, we need a placeholder (a view container) to render it. This placeholder is being provided by ViewContainerRef.

Any element can serve as a view container, however <ng-container> is a better candidate as it is rendered as a comment and doesn’t leave any redundant element in the html DOM.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container #container></ng-container>
    </div>
    <div class="footer">I am a footer</div>

    <ng-template #template let-viewName="name">
      <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
    </ng-template>
  `,
})
export class TestComponent implements AfterContentInit {

  @ViewChild("template") template: TemplateRef;
  @ViewChild("container", {read: ViewContainerRef}) container: ViewContainerRef;

  constructor() { }

  ngAfterContentInit(): void {
    const viewRef = this.template.createEmbeddedView({
      name: "View 1"
    });
    this.container.insert(viewRef);
  }
}

Both <ng-container> and <ng-template> elements will be rendered as comments leaving the html DOM neat and clean.

The above 2 steps process of creating a view and adding it into a container can further be reduced by using the createEmbeddedView method available in the ViewContainerRef itself.

this.container.createEmbeddedView(this.template, {
  name: "View 1"
});

This can be further simplified by moving the whole view creation logic from component class to the template using ngTemplateOutlet and ngTemplateOutletContext.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container [ngTemplateOutlet]="template" [ngTemplateOutletContext]="{name: 'View 1'}"></ng-container>
    </div>
    <div class="footer">I am a footer</div>

    <ng-template #template let-viewName="name">
      <div>Hi, My name is {{viewName}}. I am a view created from a template</div>
    </ng-template>
  `
})
export class TestComponent {}

Host Views

Host Views are quite similar to Embedded View. The only difference is that the Host Views are created from components instead of templates.

Creating a host view

In order to create a host view, first you need to create a ComponentFactory of the component you want to render using ComponentFactoryResolver.

constructor(
  private componentFactoryResolver: ComponentFactoryResolver
) {
  this.someComponentFactory = this.componentFactoryResolver.resolveComponentFactory(SomeComponent);
}

Then, a dynamic instance of the component is created by passing an Injector instance to the factory. Every component should be bound to an instance of Injector. You can use the injector of the parent component for the dynamically created components.

const componentRef = this.someComponentFactory.create(this.injector);
const viewRef = componentRef.hostView;

Rendering a host view

Rendering a host view is almost similar to rendering an embedded view. You can directly insert it into a view container.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container #container></ng-container>
    </div>
    <div class="footer">I am a footer</div>
  `,
})
export class TestComponentComponent implements AfterContentInit {

  @ViewChild("container", {read: ViewContainerRef}) container: ViewContainerRef;

  private someComponentFactory: ComponentFactory<SomeComponent>;

  constructor(
    private componentFactoryResolver: ComponentFactoryResolver,
    private injector: Injector
  ) {
    this.someComponentFactory = this.componentFactoryResolver.resolveComponentFactory(SomeComponent);
  }

  ngAfterContentInit(): void {
    const componentRef = this.someComponentFactory.create(this.injector);
    const viewRef = componentRef.hostView;
    this.container.insert(viewRef);
  }
}

Or by directly calling the createComponent method of ViewContainerRef and passing the component factory instance.

this.container.createComponent(this.someComponentFactory);

Now, similar to embedded view, we can also shift the whole logic of host view creation in template itself using ngComponentOutlet.

@Component({
  selector: 'app-test-component',
  template: `
    <div class="header">I am a header</div>
    <div class="body">
      <ng-container [ngComponentOutlet]="comp"></ng-container>
    </div>
    <div class="footer">I am a footer</div>
  `
})
export class TestComponent {
  comp = SomeComponent;
}

Don’t forget to store the reference of the component class in parent component’s field. The template has access only to the fields of the components.

Summary

Here we come to an end. Let’s conclude what we have understood till now.

  • We can access the DOM in Angular using different reference types likeElementRef, TemplateRef, ViewRef, ComponentRef and ViewContainerRef.
  • These reference types can be queried from templates using @ViewChild and @ContentChild.
  • Browser’s native DOM element can be accessed via ElementRef. However, manipulating this element directly is discouraged because of security reasons.
  • Concept of Views.
  • How to create and render an Embedded View.
  • How to create and render a Component View.

So, that’s it for today about understanding DOM manipulation in Angular.

Originally published by medium

HYIP Template for Website Design: Why Is It Important?

These days everyone needs a good online presence. If you want to stand out in the industry, you need to create a great brand image in front of your audience. This can be a bit difficult for you if you are not already in the business.

Before you start with your HYIP websites you first need to get the necessary knowledge, market analysis, and many more things to do. With millions of websites and ways to create and design a website, you can choose anything depending on what you really want. If you ask us, we recommend using IHYIP templates to create your website. Here is why we chose it for you:

Why choose HTML based IHYIP templates first?

We recommend that everyone search for these resources. The reason is that HTML as a language is supported by major web browsers and search engines. This will make your site readable in most web browsers and help you get better SEO rankings. Other factors clearly define the benefits of using HTML5 resources such as its ease of use, customization options, attractive layouts, rich capabilities, theme support, flexible code, clean interface, and many more.

How to get started?

The first step in starting your design process is to select and install the correct and appropriate HTML based HYIP template. This will be an important decision for you because there are many theme stores that offer you free and premium design resources.

IHYIP Templates have already attracted the attention of many designers, and their beautiful design assets help them to complete creative web projects including HTML5 templates and other hosts in a short period of time. So you can visit the site mentioned here or find a good theme store yourself, select a template and click the download button.

How are these HTML templates created?

Html5, CSS3, a framework (usually Bootstrap), JS are commonly used together to create beautiful-looking templates. Also, all the latest techniques are modified when designing the layout of these resources, so if you have negative thoughts in your mind, get rid of them right away.

These resources are built with a responsive design that fits all the purposes of your website: it can be goldcoders HYIP templates, ICO web templates, cryptocurrency exchange templates, and many more.

So basically you are free to use HTML templates wherever you want or want. We recommend that you visit the HYIP Template Gallery page and contact the best experts in the industry to clarify your concerns. Hurry up now!

#hyip template #buy gc hyip templates #hyip website design #goldcoders hyip templates #unique hyip templates

Why Is Mobile Responsiveness Important In HYIP templates?

Nowadays, mobile phones are becoming an additional part of our lives, so all businesses are interested in expanding their business ventures in mobile versions.

But mobile responsive is very important and will help your visitors spend more time visiting your site because they can check their site while moving or sitting and they are in the comfort zone whenever they want.

With mobile responsiveness, your site fits in different sizes. This is a huge advantage as it can enhance its appearance on both the big screen and the small screen.

HYIP website design

Transforming the business platform with mobile-friendly helps to attract more visitors and this leads to business success. At the same time, a high quality mobile responsive HYIP site has several advantages; See below for a paragraph on those benefits:

Boost Sales!

The HYIP bootstrap response plays an important role in establishing the HYIP site. As I said before, phones have become a part of life or a third hand of everyone, so it is easy to track or capture your customers through mobiles. You will get your mobile-friendly HYIP template which will help your site to attract more people.

SEO-friendly!

It improves your rankings in search engines. With mobile responsiveness, you can increase your SEO optimization to help your site attract more investors. By introducing your site on all social media, you can gain more attention from all visitors through SEO, which helps improve conversion rates. You may find that more visitors become investors with the help of higher exchange rates.

Easy Monitoring

It helps you to monitoring your business website easily at any instant. also It makes your investors to maintain or check out their actions on network and tracking transactions whenever or wherever they need. It’s very easier to deposit or withdraw from anywhere at any time. Having a mobile responsive business website will lead to do online business with less efforts.

Improves Reliability!

If your website is designed on a desktop without mobile responsiveness, the business website will not look as beautiful on the mobile screen as it does on computer monitors. This will definitely slow down your business. But with mobile responsiveness, your best HYIP Template will be the same on all devices with different screen sizes.

Responsive design will accommodate your investors no matter how big or small the screen. You can achieve the best user interface with your investors on all devices. Without a mobile response, your site is likely to lose investors.

Not only are the above points why the mobile response is important on HYIP business websites, but there are some of them. So let’s talk to a team of experts now to find out more about this.

#hyip template #best hyip template #buy gc hyip templates #hyip website design #goldcoders hyip templates