lucatros (9) [Avatar] Offline
#1
I finished reading chapter 5 and I have some concerns.

After creating and testing all the code, seems reactivity only works in a "per session" basis. If I have to 2 browsers opened on a given house and modify the house in any way (add a plant, delete a plant, etc), the 2nd browser is not updated automatically and I have to force a refresh to get the changes. Is this how it should work?

I think that content doesn't get updated because it's using a local copy of the object, but I'm not sure if this is something I would like to see on a modern real time app. Let's say that Guy #1 open a browser on Stephan's house. Suddenly, the phone rings and this person leaves for 15 minutes. In the meantime, Guy #2 opens Stephan's house page on another browser and start modifying it. Guy #2 can even delete Stephan's house and Guy #1 won't even know about it until he refreshes the page. Most important, after Guy #2 deletes Stephan's house, Guy #1 can still edit it and if he clicks on Save, Stephan's house will re-appear on the DB.

Is this the intended behavior?
stephan.hochhaus (92) [Avatar] Offline
#2
You are right, it's not optimal yet.
As said here there will be some major rework to this chapter.
alanb (11) [Avatar] Offline
#3
I am learning Meteor and all tutorials that I've done imply that reactive editing is handled by Meteor. Is this correct?
If so, Chapter 5 could mention this and stress that the techniques described are only required in high volume cases.
In which case, most of the chapter could be ignored by beginners like me?
Great book and have learnt lots already.
stephan.hochhaus (92) [Avatar] Offline
#4
Actually I intend chapter 5 to illustrate the mind change required to think about reactive editing interfaces. Most devs I have met that came into contact with Meteor still try to put their DOM-skills into action when working with UIs. While it certainly works it is not the easiest way and rather cumbersome. The fact that Meteor does reactive wiring for you and the old-thinking will conflict with each other and - from my experience - developers need to be made aware of how little they should actually do smilie

In chapter 4 you learn how CRUD works and it aims for quickest results and a simple scenario. Chapter 5 takes it a step further and readers will not only need it for high-volume scenarios but for all.

That said - do not ignore chapter 5, it is there for a reason smilie
andersr (17) [Avatar] Offline
#5
I am currently working through this chapter and wanted to add that I started to get confused during the introduction of the array index section (5.4.1) - I think you need to do a better job of explaining the benefit/purpose/need/whatever of adding this index. It's not at all clear to me why we are doing this and it just seems to add complexity.

Toward the end of the section, you talk about how there is “no more need for a compound ID mashed up of house ID and plant color as you did previously” which is all good and well, but only show adding data-index="{{index}} to plantFieldSet while still using data-id="{{../_id}}-{{color}}" in plantDetails.

I feel as if the original discussion of how to enable editing/updating has been lost or been made overly complex.
stephan.hochhaus (92) [Avatar] Offline
#6
andersr wrote:Toward the end of the section, you talk about how there is “no more need for a compound ID mashed up of house ID and plant color as you did previously” which is all good and well, but only show adding data-index="{{index}} to plantFieldSet while still using data-id="{{../_id}}-{{color}}" in plantDetails.


I hope
@index
will come (see this PR)and make the indexing superfluous, but probably it will not be available before we go into print smilie

The index must have slipped through when we rewrote the chapter, I will check that the plantDetails index is correct.

I'll revisit this section.