@rmemoria
IT Consultant and developer
Nothing here yet.
Nothing here yet.
No blogs yet.
Hummm... In this case, when async call returns, call the parent component forceUpdate() function, making render() of the parent to be called again, so you'll be able to pass the new property to the child component. If you just want that specific child to be rendered, you'd better use an event dispatcher or more advanced libs like flux or redux.
In order to make the exemple as simple as possible, I'm using the component internal state to control if the asynchronous call has already returned or not. Like that: class CardComponent extends Component { componentDidMount() { const self = this; server.getSomeData(data => self .setState({ data: data })); } //This render is begin called even before props getting updated render() { return ( <div> <h1>{ 'This will always render' }</h1> { this.state && this.state.data && <div>{ 'This will just render after the return of the async call' }</div> } </div> ) } } The trick here is to use the component internal setState. Every time you call setState, React will force the component to render again. So, suppose you have an asynchronous function getSomeData that will call a callback function when data is fetched from server. When this function is called, I set the state of the component with the data and the render function is called again. Inside render, I use an AND operation to check if the data property is available in state. Since state is not initialized by default, I have to test if state and state.data are available. Because in JavaScript, the result of an AND operation is always the last expression (from left to right), it will return the <div> to be rendered. This is a very simple technic, but it works pretty well... When you get deeper into React, you'll find a lot of best practice guides recommending to avoid the use of internal component state (for example, stripping out the async call from inside the component and passing the data as a component property), which offers some advantages in terms of maintainability. But that is another history...
Worth learning? No... Just if you have to maintain legacy systems using that. I'd forget about JSP and JSF. Both of then have their drawbacks... In my opinion, Oracle is in a dead end with these technologies. If you are interested in server side rendering, spring comes with better options, like Freemarker, Thymeleaf and Mustache.
It seems to be a natural evolution of the technology. Probably it will take time for its adoption, but as the requirements for more complex apps and pages emerge, more people will move to it. I read an article explaining the reduction in size of the code compared to pure java-script. Another benefit is its sharing mechanism with JavaScript - Apparently you will be able to use WebAssembly modules in your JavaScript code, so I see a great future for libraries and modules that require some performance to be written in WebAsm and JavaScript code will be its consumer.
I love jQuery and 5 years ago I couldn't imagine any web app without jQuery. But today is different - JS, HTML and CSS has evolved a lot, and new frameworks have emerged to solve different needs. Right now I'm working on a SPA web app without jQuery and, surprisingly, I'm not missing it at all. jQuery is fantastic for DOM manipulation, but IMO, as development in client side became more complex, the need for a more rubust, modularised and flow-control has grown up, and the core jQuery can't help much on that. If I had to bet on the next 10 years, I'd say that this jQuery we know will just support legacy apps.
My experience with Meteor is almost zero, but I've read articles about it and its documentation, so I'm talking about by my own experience... I get skeptical when I see a solution promising to solve your problems easily. There is always that moment when you need something more specific and is already implemented by that solution in such a way you can't change it. It sounds like MS Access (in its own proportions). Probably developers feel a lack of faith on Meteor because of a all-in-one solution like that. For example, I'd really consider using Meteor for a web site, blog, simple web applications, but not for a complex information system (at least by now). Probably I'm wrong, but this is the way I feel. The lack of success cases about Meteor being used in big apps doesn't help much.