The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

450521 (1) [Avatar] Offline
Hey Nader, this is Chris who you might be working with on that brooklyn thing w/ JC.

Anyway, as a Rails guy, there are a couple things that didn't make sense to me, then did, so thought I'd give you the feedback/my suggestion then let you rearrange as you see fit. I'm not through the todo list app example implementation yet, but thought it would be better to give feedback while I'm in it, as opposed to trying to remember later.

First: At the start of the book, why all the focus on exporting components? As a Rails guy, as long as your base folder is in the autoload paths for the app you can then freestyle namespace to your heart's content. So you end up being able to create code over in one area, then call it no problem in another as long as it adheres to convention. So all the focus on exporting components, to me, was like, huh? Why is this so important?

Well, for two reasons. The obvious one is avoiding code duplication. The non-obvious is because of directory structure. If you're gonna share your components with ios and android, and you want to manage all this from one succinct codebase, really the emphasis on exporting components is introduced by how you're gonna set up your directory structure. Since I've no background in large js-ecosystem-based codebases with a lot of js, I was missing that context on how they're set up. Once I saw the '/app/App.js, app/Header.js' etc, everything clicked and it was like "aha! ok. Now this makes sense." But I did go through a chapter or two completely confused and found it harder to engage with the "here's what you should know" because "why you should know this" was not clear to me. You need to know how to import and export because, we'll be using a directory structure like this, and it affords these benefits, and (?) while there are not true "standards" this is by and large what you'll see in large JS codebases.

Second thing is that destructuring arguments is mind-bendingly confusing to me right now. On page 19 you go into "this destructuring lets us avoid the need for all this extra code to import something." This might be a tall order, but I can understand well enough how to actually use destructuring, but it seems magical and I don't like magic. Might sound weird coming from a rails guy I know, but I feel a large sense of uncertainty from not understanding the basis of it since its use is everywhere. My question is, what is the smallest thing you can explain about how destructuring works that explains everything else? There has to be a logic and basis to it (because technology is never truly "magical"), but I'm not sure what context I'm even missing to be able to "get it."

Is it a set of syntactical recipes which are equivalent to each other? so then I just have to memorize their forms (then it might just be, old syntax -> new syntax). Is it a convention that allows the computer to make useful assumptions for you? ( const obj = { destructuring: 'omg' }; const { destructuring } = obj; -> now when you call "destructuring" it gets the equivalent key in the obj object? how should I be thinking about the context of where the code is executing and the difference in before/after to explain how and why this can happen?)

This second part I know is understanding JS better, so on one hand, maybe it doesn't belong in here. On the other hand, if a bunch of other rails devs use this book and they're recipe-copiers instead of people who actually understand how and why things are working, thats no good.

Final little things that tripped me up: I very well could've screwed something up, but in the stylesheet for the App component of the TodoList example, setting 'content: { paddingTop: 60, flex: 1)' made it so nothing would show up on my ios simulator. Had to get rid of 'flex: 1' and it all seems to be working correctly. I ran my code past some people in the reactiflux discord and nobody there caught it, either, and recommended I look into how my environment is set up.

On pg. 58, in the import statement to pull the Heading component into app: "import Heading from '/Heading'" -> it's obviously supposed to be './Heading'. Except this was the first time I actually pulled in a component, and it wasnt working. Eventually I figured it out (once I realized imports always happened from the context of the file). Just calling this thing out specifically because as the first import in the first actual code-to-editor place, his is not the right time for that to have a typo lol.

Anyway, been super fun so far. Would also appreciate a general landscape of your own personal tooling recommendations around getting everything set up (ex, in ruby land, you have some ruby version managers rbenv and rvm. then you have bundler. once you've taken care of these two pivot points, you're good forever.) I got going using nvm, but just some general choices/explanations of each and then your default pick among those and why would be SUPER appreciated.

Actually, FINAL thing, I've had friends pick up then drop react native because it was too slow (they were doing it with video stuff). This showed up on HN the other day:

Will the native sections be addressing some common ways to tackle memory management with pictures and stuff?
287516 (45) [Avatar] Offline
As far as exporting goes, thanks for pointing that out, maybe will update chapter 1 to guide people into this concept a little better.

Destructuring is used a lot in React / React Native codebases because we are passing so many objects around and we just don't want to keep saying props and this.props over and over, though I agree at first it is not evident when using these examples the benefits because we are working with such small examples. I may also update to clarify the reason, that reason being less repetition and a more concise codebase.

As far as memory management goes, I don't think that going in depth for a book like this makes sense. I think it would qualify as an advanced topic considering my experience with it so far, and the fact that I have yet to have any issues with memory in multiple production apps as long as I am following basic programming principles and best practices.

I appreciate the thorough comment and the heads up about the errors that tripped you up, I will update these in the next release as well smilie