ANN: New knockout.mapping maintainer wanted

[Roy Jacobs]

Hi all,

I have worked quite happily on the knockout.mapping plugin for the past few years. However, in my day job (at Civolution, we're hiring! :)) I have moved away from doing C# and Javascript development to an architect role. Combined with family additions on the horizon I really don't have a lot of time to work on the plugin anymore.

This results in quite a few pull requests and issues laying dormant and a general lack of improvements.

So if you are interested in taking on the challenge of maintaining and updating the plugin, please step forward here!

With regards,

Roy

[Michael Best]

What do you think of Dave Herren's knockout.viewmodel (https://github.com/coderenaissance/knockout.viewmodel)? It looks like he's actively maintaining it, so maybe it could become a replacement for knockout.mapping.

--  Michael

[Roy Jacobs]

I think it's an excellent replacement. The only gotcha is that the syntax is obviously different, so it may be inconvenient for people to have to switch to another plugin.

However, it doesn't have to support the legacy mapping syntax of the mapping plugin and TBH I even prefer ko.viewmodel's configuration syntax.

Is there any way I can help with a migration path?

[Michael Best]

Dave, what do you think?

[CodeRenaissance]

I'd love to support this.  I'm about to release the next version of the plugin which contains a few bug fixes and a switch on the update method to eliminate long running script errors on older browsers.

I wanted the plugin to be good at only one thing, the easy, flexible creation of viewmodels. This is one of the reasons I ruled out trying to shoehorn in the legacy syntax... users would have wanted a 100% match for the legacy behavior, which would have complicated and slowed down the code and made moving forward more difficult. I would prefer to continue to limit the scope of the project as much as possible.

A few questions:

Do you see this affecting the scope of the project? 

How can we move forward on the migration?

[CodeRenaissance]

I could probably add documentation on switching from ko.mapping to ko.viewmodel. In many cases minimal changes could be made. I could show a few simple refactorings. 

How do I go about incorporating my documentation into the knockout site?

[CodeRenaissance]

Oh and looking at the original question, when I said I'd love to support this, what I meant was I'd love to have ko.viewmodel as a official plugin that replaced ko.mapping which would mean committing to support my plugin on an continual basis as it would become the main plugin people use. I just realized that could have been taken as saying I would support the mapping plugin. Sorry if there was any confusion. I had just woken up. 

[Roy Jacobs]

I think there should be a number of steps:

* Officially announce the 'going into maintenance mode' of the mapping plugin. I can still do this maintenance and accept the odd pull request here and there, but I won't be actively adding features.

* Announcing the official replacement, being viewmodel

* Do we want to move the viewmodel documentation to the official knockout documentation page? (where now the mapping docs are located?) David: This would involve you simply forking the official documentation gh-pages repo and creating a pull request with the new docs and links and whatnot.

* As a migration path, document potential workarounds and guidance for features that are not supported by viewmodel

Anything I've overlooked?

[CodeRenaissance]

Sounds like you've covered everything. Let's move forward. I'll release the next version by Sunday and, assuming that we want to update the knockout documentation page, I'll plan to have a pull request by the 24th -- this would be sooner but we're wrapping up our final sprint before a beta release to a client and I'm out of town next weekend. In any case that will also give me some time to handle any bugs that are reported from the release.

[Ω Alisson]

Is it possible to use knockout.viewmodel to populate an existing viewmodel that was not created with it?

--
You received this message because you are subscribed to the Google Groups "KnockoutJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to knockoutjs+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[CodeRenaissance]

Do you mean to update a viewmodel that was not created with it? Can you describe the scenario? Are you manually creating a viewmodel that you want updated?

[Ω Alisson]

Exactly!

[CodeRenaissance]

In general there is no reason why it shouldn't work as long as your viewmodel is limited to json, functions, observables, observableArrays and computed values. Here's a simple example: http://jsfiddle.net/g2AEf/. This will not work however if you use constructors to create your model or parts of your model like this: http://jsfiddle.net/hcz5F/. The logic in ko.viewmodel was simplified and sped up by limiting the input to only json. In this case the path that should be followed tests for constructor === Object which is false because the constructor is the viewmodelType constructor not Object. Hope this helps.

[CodeRenaissance]

Need another week... added ko.viewmodel.mappingBuilder to create options object. I got some feed back from coworkers who were using the plugin but weren't as comfortable in javascript that they would prefer a dot syntax. The old style will still be supported(and documented)  but the documentation is going to present the dot syntax as the primary way of doing things. These changes are complete and unit tested but I'm still working on the documentation.

[CodeRenaissance]

So this means you could do

var mapping = ko.viewmodel.mappingBuilder()

     .extend("{root}.path",

                  function(item){
                  }

      )

      .extend("{root}.path2",

                  function(item){
                  }

      )

      .append(["{root}.path3", "{root}.path4", "{root}.path5"]);

var viewmodel = ko.viewmodel.fromModel(model, mapping);

[Roy Jacobs]

How is this coming along? Any news?

[CodeRenaissance]

I have most of the documentation done, and I have put in fixes for a few bugs that came in. One of the bugs revealed that nullable objects could not easily be handled and updated properly within the existing framework. To fix this I added flagAsNullable which ensured that these would be handled correctly.

Also in writing unit tests for the bugs though I ran into an edge case that lead me to believe that extend should have never have had an unmap. I was using extend to do two things: 1) transform object and values (map and unmap) and 2) to extend observables post mapping. Extend works great for #2 but did not work well for #1 in many cases and #1 was the only reason unmap was needed.

To handle this I have removed extend unmap and am adding transform map and unmap. The transform map function fires before mapping and before update and the unmap function that fires after unmapping. This also fixes the problem that extend didn't fire during update.

Sorry to take so long on this and for not providing an update.

What I have left is:

• code:
• transform update code and unit tests (transform map and unmap done)
• docs:
• transform
• flagAsNullable
• revise the extend
• reread/polish remainder of docs

ETA August 5

[Roy Jacobs]

Excellent news! And no need for apologies, I was just curious :)

Op 25 jul. 2013 19:53 schreef "CodeRenaissance" <David....@yahoo.com> het volgende:

--
You received this message because you are subscribed to a topic in the Google Groups "KnockoutJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/knockoutjs/0cZAAVloRDw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to knockoutjs+...@googlegroups.com.