matreshka-forum

Open full view…

Some thoughts of a novice user

muutuser890765
Fri, 29 Apr 2016 21:50:05 GMT

Hi, I found your framework when looking at this page: http://www.roblog.io/js-repaint-perfs I must state that I am not a hardcore web developer, I am more like a back end programmer who needs to do UI. I know a bit of Javascript, some jQuery, some Angular, but these tools all seem to be huge and need dedication and time to understand them. So I was looking at something small and simple and easy to understand. I liked your approach - why pollute HTML with mustaches or other with markers like "person in persons" when we can access DOM elements by ID or class, so there is no need for these markers altogether. My comments are from a very unexperienced Javascript developer, but hopefully they help making your library even simpler and cleaner for a casual user. So, without further ado: jset -- what does the name mean? Set for JSON? Why not camelcase? I would prefer a more descriptive name like serverData or publicData (as opposed to privateData which is not sent to the server, not used in toJSON(), etc). linkProps -- took me some time to get used to the name. First I was r eading it like a noun: "properties that are for linking" instead of like a verb "go link those props!". Also, it is not about linking properties, it is about creating a new calculatedProperty. Would like the name changed. sandbox and other magic properties -- for some reason I feel ok with having a bunch of methods defined, but a magic property seems like a hack. I know that a method and a property are two sides of the same coin, so no reasonable argument can be made against built-in properties... I would feel better if this were a method not a property, but this one is a matter of taste. on() method may take a DOM event, and you need to call preventDefault() to avoid default browser action. This feels to me like HTML smell that crawled into model. I would prefer model to have as little knowledge of templates, DOM and rendering as possible. On the collections, component nesting/interoperation and rendering: in the Matreshka.Array example you have User inside of Users. I like how users and user_template defined, in HTML and without mustaches. I can understand explicit call to recreate() to display User list, although I think that normally this should be done automatically. Container - another magic property? Then comes my biggest gripe: itemRenderer: '#user_template' is defined on Users not on User. Why? First, I was hoping to get away from React / Angular2 idea of combining template and model into a big fat component, and here you go, linking the model to a template. The model specifies a renderer, whereas it should be the other way around, a renderer should use a model. Model should not care how it is being rendered. Even if I accepted this idea, I still don't get why renderer for User is specified in Users. This means that if Users to use some other User implementation it needs to change value of itemRenderer. Also, when I try to approach this fully modularly, I look at User and I cannot understand how it is rendered unless I look at its parent object, Users. What if I wanted to put User into other model? In short, I think that itemRenderer should be specified for model that is being rendered, that is, itemRenderer: '#user_template' should be specified on User object, not Users. But in the best case rendering stuff should not be specified in model at all. I think this is sort of information that should be specified on HTML template, not in model. As I understand, calling Users.recreate() invokes User.on('render') ? Why not renaming recreate() into render() for clarity? I don't want to keep track how all these names are related to each other. setValue: function( v ) { this.innerHTML = v; } is HTML smell in model. Can this be avoided? The template should be filled one way or another... Why do I need to call innerHTML? Does not the library already bind TD elements to model properties? I am in render handler, so rendering is in process, the template is defined, the model properties are bound... why the necessity to explicitly call this.innerHTML = v ? These are just some preliminary thoughts :-) I think the library shows great promise, but so far it does not feel slick and perfect :-) I wish it were sensible, small, fast and easy to understand. Wish you well!

Андрей Губанов
Mon, 02 May 2016 10:35:08 GMT

Thank you for long message :) > jset — what does the name mean? Set for JSON? Why not camelcase? I would prefer a more descriptive name like serverData or publicData (as opposed to privateData which is not sent to the server, not used in toJSON(), etc). I also don't like this name but I keep it because cannot find better short name for setting "json properties" or "data properties". `setServerData` etc is too long. > it is about creating a new calculatedProperty It may have sense because as you may notice English isn't my native language. `linkProps` sounds for me like a verb, plus this name is short (I really care about short names, I like Python approach). If you have some ideas how to name this method, let me know. > a magic property seems like a hack Agree. But all this time I couldn't find better way how to implement nice sandbox-like logic without using properties. Matreshka is mostly original framework, not just "better than React/Angular etc" and I can't just borrow ideas from another framework. > I would prefer model to have as little knowledge of templat es, DOM and rendering as possible. Matreshka is not about patterns and strict requirements like Redux has. It's just about how to write applications easier. If you don't like to define event handlers using Matreshka#on, just don't do it. It's not required but I found it useful becausse you can keep all events (model, DOM. custom etc) in the same place. > think that normally this should be done automatically In some cases automatic behavior isn't needed. > Container – another magic property? Yep, as I said above I also don't like it but don't know how to get rid of these two "special properties". > Then comes my biggest gripe: itemRenderer: ‘#usertemplate’ is defined on Users not on User. You can define `renderer` property for User instead of `itemRenderer` for Users. > As I understand, calling Users.recreate() invokes User.on('render') ? `recreate` removed all existing items from an array and adds new ones. ```js const arr = MK.Array.from([1,2,3]); console.log(arr); //[1,2,3] arr.recreate([4,5,6]); console.log(arr); //[4,5,6] ``` > setValue: function( v ) { this.innerHTML = v; } is HTML smell in model. Can this be avoided? You can predefine all binders in their own places and then reuse them. Look at [Matreshka.defaultBinders](https://matreshka.io/#!Matreshka.defaultBinders) and [Matreshka.binders](https://matreshka.io/#!Matreshka.binders) > why the necessity to explicitly call this.innerHTML = v Because Matreshka doesn't know how to bind property + node when node isn't standard commonly used input. You need to do it manually. > Wish you well! Thank you!

muutuser890765
Mon, 02 May 2016 16:13:45 GMT

Thanks for the reply and for the tip about using renderer instead of itemRenderer!

muutuser890765
Mon, 02 May 2016 16:29:27 GMT

It would be nice to have this "renderer" property already defined in the library ;)

finom
Sun, 18 Sep 2016 19:16:00 GMT

Hey, check this out: https://github.com/matreshkajs/matreshka/releases/tag/v2.0.0-alpha.0