Dynamic View URL

[mstdokumaci]

Current view query gets only one parameter, which is name of view:

<div data-query="view('ViewName')"> </div>

Which means View init function gets no parameter. What if we want to decide template URL at init? I mean what about this:

App.View('Svg', {
  init: function (file) {
    this.options.url = 'my_img_folder/' + file + '.svg';
  }
});

<svg data-query="view('Svg', 'icon_name')" />

Or any other way to decide url on init. Is it possible anyway?

[astoilkov]

Hi @mstdokumaci ,

It is not possible to pass arguments to the View init method. That is on purpose because multiple elements could associate with the same View and handling parameters because hard and inconsistent. If you want to achieve your scenario you will have to do something custom. For example you could use a custom query to set the View url before it is initialized:

blocks.queries.setViewUrl = {
  preprocess: function (view, url) {
    view.options.url = url;
  }
};

<div data-query="setViewUrl(Svg, 'icon_name').view(Svg)"></div>

[mstdokumaci]

Thanks for the quick reply.
This brings to my mind another issue. I see you give some answers including a custom query which takes view as a parameter. Maybe any query should be able to reach the current view internally.

[astoilkov]

You can. It is part of the context.

blocks.queries.customQuery = {
  preprocess: function () {
    var view = blocks.context(this).$view;
  }
};

However, in your scenario you can't use this approach because you will need to call setViewUrl before you are in the view.

[mstdokumaci]

I guess this is because view options are not expected to be altered after init. Actually I'm kinda forcing the ng-include way of Angular or directive template attribute. This approach is OK for now but I think a little bit more felxibility is necessary for views. Some way to write a function which runs at / before view init which can read data from actual context and alter view options.

[astoilkov]

Yeah I agree with you. Can you provide a little more information about your scenario - I am wondering why you need to do this before View initialization and can't do it in code. I just can't wrap my head around in which scenario I will need such approach and can't just use a different approach for solving it in code.

[mstdokumaci]

I know this is an AngularJS point of view. It is the most used two-way binding framework so I'm going to make my suggestion this way.
jsblocks views are the most close thing to angular directives. But it lacks some of important features, which angular directives has.

1- Angular directives can catch elements by a selector, jsblocks views should be recalled by name for each element it supposed to affect. Something like this would be real handy:

App.View('Icon', {
  options: {
    selector: 'img.icon'
  }
});

Let's say this matches each element which can be reached by:

document.querySelector('img.icon')

So our HTML would be more lean:

<img class"icon" data-query="view(Icon)" /> //Instead of this
<img class"icon" /> //We would use just this

2- Angular directives has the template or templateUrl attribute as a function. So you can alter the template on directive init depending on element attributes.

app.directive('directiveName', function() {
   return {
       restrict: 'E',
       templateUrl: function(elem,attrs) {
           return attrs.templateUrl || 'some/path/default.html'
       }
   }
});

3- Also directive link function (which is something similar to view init function) has access to DOM element attributes. This helps reusing same directive in code with some parameters. If jsblocks views has the feature it would help coding more customizable views.

[KrishnaPG]

The appView.options.selector capability is very neat (and non intrusive for existing html templates). Would be great if it is supported.

[Kanaye]

I get the point but I think we should think about implementing this in an other kind of module because a View is a singleton in jsblocks and changing this would overcomplicate some of the internals (e.g. routing).
Maybe this could be part of the component system once we figured out how we want it to work.