It's slightly less easy to read than <li ng-each={myList}>...</li>
But it means you don't have to learn a library's HTML API.
Or when you want to loop through myList, but exclude a few particular items... you know how to write that in JS, but have no idea what to do in the mark up language. You could create a filteredList, but it's often not ideal
I cannot really understand how today mixing logic and presentation in JSX is considered a good thing.
The first principle when writing complex systems should be to completely separate the logic from the presentation layer.
Nowadays people seem happy with intermingled monstrosities like the one shown in the JSX code upstream.
I think I understand it quite well having worked for more than a decade on complex systems.
I can't say the same for you if you think that putting some logic in the presentation layer like the example above is a good thing.
I would always transform my domain in the model object while the presentation layer should only present the transformed model.
Using a map function directly in JSX is a sure recipe for disaster in a complex system.
But I seriously doubt that you can understand this looking at your answer.
He is right taught. You are allowed to have all the logic you want in your presentation layer. As long as it is presentation logic this perfect. If it is "Business logic" then this is wrong. Have you realised than having a if statement is already "logic"? Template system that don't have if statement are absolute trash IMHO.
Ah ok.
So for you using a map with a ternary operator over a list of objects in JSX is perfectly fine and you can't see what is wrong.
I don't know Vue.js, but in WPF I would have simply bound an ItemsConttol to the list of models.
Stop. Finished. No presentation logic at all in the XAML file.
WPF will automatically bind the correct DataTemplate to the specific ViewModel contained in the list.
I would have never ever approved a pull request in which someone implemented that using a monstrosity similar to the one shown in this thread.
The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model.
Reading this thread, apparently in React is encouraged to do whatever sh@t you want directly in the JSX file rather than delegating it to where it belongs.
Heck, you are even excited that JSX is Turing complete, as if it was a good thing.
I will continue happily to write my code respecting the separation of concerns, leaving all the logic out of the XAML or HTML.
You are free to continue to put everything in the JSX if you like it, but don't expect me to stay silent when you mislead many people in thinking that writing logic in JSX is the right way to go.
> So for you using a map with a ternary operator over a list of objects in JSX is perfectly fine and you can't see what is wrong
I don't really know JSX much and without a specific example this is pointless to discuss. But basically JSX is syntactic sugar over javascript. A ternary is just a "if" condition so I don't see where is the issue here. Are you really using a template language devoid of conditionals? Even mustache the "logic-less" template has a form of it.
> The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model
The role of the model is and has always been to handle /business/ logic not presentational logic. If you put your dirty presentational logic inside my models I can tell you I will /never never/ accept your pull request.
Instead of this monstrosity in XAML would be like this:
<ItemsControl ItemsSource={Binding ListOfThings} />
But of course for you is better the JSX code.
Luckily for me you will never have to review any of my pull requests, I seriously doubt that you can accept something that you don't understand.
No, but he knows that templating languages have been wrestling with pretty much the same three or four issues since the beginning of HTML templates. It gets old.
It gets really old to see people try failed experiments over and over again, which pretty much is what you are suggesting.
Also, you got some display logic in your examples there, buddy. If you can't see it then no wonder this conversation is going in a circle.
What is that if not an horribly verbose switch case for modifying the representation of different elements passed to the ItemsControl?
I am not advocating that the JSX is particularly pretty or clever. I am objecting to your crazy notion that there should be no logic in the representation layer.
I asked you to please don't speak about things that you don't know.
The page that you linked has nothing to do with presenting multiple items with different types.
It is defining the visualisation of the control itself, defining the arrangement method for the contained items, defining the same visualisation for each item and finally it defines the container visualisation for each item.
To replicate the JSX logic in the example discussed the code that I posted is all you need.
It will bind the source of the ItemsControl to a list in the ViewModel that contains the different ViewModels that you need to display.
WPF automatically will find the DataTemplates defined for those ViewModels and use that in the visualisation.
No if, no switch, no map and nothing at all in the XAML file.
Just:
I think you are comparing Apple with oranges here. React doesn't have a ViewModel notion that would binds data with Component. The binding is happening in the templates themselves so in the Component themselves and there is no in-between layer AFAIK.
If you are looking for exactly this feature you might be disappointed.
I have used those 2 frameworks in the past. Could you point me to the documentation about ViewModel in Vue.js I wasn't able to find anything relevant other than:
> Although not strictly associated with the MVVM pattern, Vue’s design was partly inspired by it. As a convention, we often use the variable vm (short for ViewModel) to refer to our Vue instance.
I am sure it wouldn't be very hard to develop such a layer within React if needed.
It's useful to separate mantra and intent, here. Yes, separation of concerns is a useful thing, but if you just take it to mean that no logic should ever be involved in your templates, you're taking it too far and unnecessarily complicating things. If a section of the page is scrollable or expandable, the scroll and expansion state (and event-handlers) clearly live in the presentation layer and don't belong in any of the data model. (They aren't the only examples, but they are ones that most people accept.)
Yes, that's easy, but adding something to your model just because your view wants it rather seems like the cart driving the horse. If your view needs something that your model otherwise has no use for, then it does not belong in the model.
There's no real clear cut line where you can say that a model had no 'use for' a certain field.
If your point of view is that a model is meant for more than just doing the view, then yes, adding view only fields may pollute it for others (e.g., analytics).
But if your model is meant to drive the view of the app, then the story is very different. And some times you can't even tell if the model is just there to drive the view our not, since requirements change often.
You most likely certainly can with nothing to worry about. 99.99% of the world's developers will never need to sue Facebook for patent infringement. That is, unless Facebook begins reverse patent-trolling. But I see it as more of a decision on ethics at this point in time, and don't really see any reason to feel particularly threatened.
Meh, it's more just disrupting premarital pregnancy prevention.
Premarital sex has been huge since the invention of marriage, really hard to disrupt something that established. Denial is a pretty good app for it, try downloading that?
And yea this is a solid disruption to immorality, you're right! Now a person can get the medical care they need, even when local doctors would want to deny it based on their own religious beliefs.
I thought of it since a buddy has some Tiki Bar that he wanted a site for, and I really didn't want to drop into WordPress or anything serious. Knew he could handle a spreadsheet.
Checkout http://www.tarbell.io/ - It's a CMS designed around google sheets. I think it's a bit of setup, but might be a solid solution.
It's an interesting idea - here are some issues to consider:
1. Joining data will be very slow. If you need to access 500 database to get the "comments" on a "post", you're going to have issues.
2. How will you change the database structure as you iterate?
3. Storage cost of data is so low, that by the time you would start paying for data, you would have greatly exceeded the capabilities of Google Sheets.
4. Google sheets are slower than databases - there are no indexes, keys, the data is not stored in a way meant for most db operations (selections, etc)
I'm sure theres more but these seem to be the biggest ones for me.
That said, you should definitely try it - it's an interesting project at the very least.
Storage costs are not low. They are free since Google Spreadsheets do not count towards your Storage Limits. You'll be limited only by the 2M maximum cells a spreadsheet can hold.
But it means you don't have to learn a library's HTML API.
Or when you want to loop through myList, but exclude a few particular items... you know how to write that in JS, but have no idea what to do in the mark up language. You could create a filteredList, but it's often not ideal