@setTemplate(newTemplateName) class method about meteor-blaze-components

[mitar]

Yes? I do not understand the question here? I do not think this has to be in the core, you just define a base class for your components, which provide that. You could do something like:

class TemplateComponent extends BlazeComponent
  constructor: (@customTemplate) ->

  template: ->
     @constructor.customTemplate or @customTemplate or 'TemplateComponent'

Then one can do:

{{> TemplateComponent args 'MyTemplateComponent'}}

Or:

TemplateComponent.customTemplate = 'MyTemplateComponent'

You could also make it a class method. Or anything.

So I am not sure here, is this a question? Or request for such a feature? I do not think this has to be part of the core because it depends too much on how you want to do it.

[Sivli-Embir]

Ah sorry, no your right. Long day.

class TemplateComponent extends BlazeComponent
  constructor: (@customTemplate) ->

  template: ->
     @constructor.customTemplate or @customTemplate or 'TemplateComponent'

Perfect. I feel like this could be in core but it is certainly not required. Reason being, I will have to create a new root component for the package with this code in it. If others start doing something similar being able to swap out templates could be very useful.

[mitar]

So yea, I already have my personal base class I am using, so that are some additional helper functions I find useful. :-) But I am reluctant to add it to core to not pollute the namespace too much. (I am using components also with other types of classes, which have their own set of methods already, so a list of methods really grows. Like, for example, a great use case is combining PeerDB documents with components. Then you have a rendable documents stored in the database. But the base class is then not BlazeComponent, but PeerDB's Document. But Blaze Components were designed that this works.)

One thing is that I would like to see a bit more how patterns evolve and then we can have a wider discussion what should go to core.

Another my hope is that this could be addressed with mixins. So if you would want an overridable template with some API to do it, you would just use a mixin which would do that in your component. But currently template is the only one which does not really provide a mixin extension point by default. Maybe this could be something to be added.

I would not like to provide official way to replace a template "under the hood" of another component, without that component providing you an explicit API to do that. So if a component wants to provide such an extension point, then yes, it can be such a base class (which is less reusable) or mixin (which is better, but not yet supported).

Because if you want to replace a template under the hood, then you can simply do:

InputComponent.Checkbox::template = ->
  'myCheckbox'

[Sivli-Embir]

Makes sense on all points.

On a side note, very glad you separated PeerDB and this. I like aspects of PeerDB, used it for a while even, but it just did not fit my workflow.

[mitar]

I like aspects of PeerDB, used it for a while even, but it just did not fit my workflow.

Would love to learn more about why PeerDB was not suitable for you.

[Sivli-Embir]

Disclaimer: this is a quirk of mine. Not trying to bite anyones head off :)

So its been over a year since I used PeerDB so this may be less relevant. I believe I stated this back then too.

Basically my issue with all the other model packages out there is I disagree with the schema & persistence pattern. I feel that strict-typed schemas are backwards. JS and Mongo are both functionally typeless so why do we keep trying to impose a typing layer.

Now that said, my issue with PeerDB was its actually its lack of schema enforcement. There should be some way to check the data but I think it should be functional, not typed. I currently use the shadow packages to implement my solution, but it is young and slow growing. If your interested see:

https://github.com/Meteor-Reaction/shadow-schemas/
https://github.com/Meteor-Reaction/shadow-models

Sorry about how bad the docs are, I am happy to explain if you want to make some issue over there.

[mitar]

Basically my issue with all the other model packages out there is I disagree with the schema & persistence pattern. I feel that strict-typed schemas are backwards.

Oh, we use PeerDB with polymorphic types. :-) You do not have to have a strict types? You just classes. Who is talking about strict types?

So you store documents into the same collection and then based on one field in that document it instantiate a different CoffeeScript class, so you can get different methods. Really cool.

Now that said, my issue with PeerDB was its actually its lack of schema enforcement.

It would be really easy to add, but I have not need it. :-) Somebody could add it, but people rather see implementing their own stuff. :-)