[1:11 PM] jswannabe: Question regarding npm. I had a debate last week with someone at work regarding npm update. I don't like running it since the latest updates from 3rd party libs/modules that my webapp might get might break. There is another dev who's on my side. However, there is another dev that likes running npm update. Our boss likes it too and says that we should always get the latest changes from 3rd parties. For me, I'd rather run npm update on a test branch first and if it's been proven not to break our app, that's the time we'll introduce the new version. It's been an ongoing debate for months now, LMAO! How are you folks doing it at work?(edited)
[1:14 PM] acemarke: My personal suggestion would be that you don't just randomly update libs
[1:14 PM] acemarke: I would agree it's better to do it on a test branch first
[1:14 PM] mruzekw: If they respect semver, there shouldn't be breaking changes? I could be wrong
[1:15 PM] acemarke: that's the theory, but in practice, thi
| // The `loader` prop is a Dataloader instance | |
| // https://github.com/facebook/dataloader | |
| class Dataloader extends React.Component { | |
| state = {data: null, isLoaded: false}; | |
| componentWillMount() { | |
| this.prefetchData(this.props); | |
| } | |
| componentWillReceiveProps(nextProps) { | |
| if (this.props.id !== nextProps.id || this.props.loader !== nextProps.loader) { | |
| this.setState({isLoaded: false}); |
tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.
A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.
But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.
How do we solve this with React?
| package demo; | |
| public interface Node {} |
| // @flow | |
| // Helper to extract inferred return type of a function | |
| type _ExtractReturn<B, F: (...args: any[]) => B> = B; | |
| type ExtractReturn<F> = _ExtractReturn<*, F>; | |
| // Use constants as normal | |
| const AGE = 'AGE'; | |
| const NAME = 'NAME'; | |
| // only need to provide types for arguments in action-creators |
[10:39 AM] infected mushroom: Is this analogy correct?
Can we say that the store in the Redux app is like a database?
mapStateToProps is used to retrive (read) the information from the database where as
mapDispatchToProps is used to write the information in the same database?
[10:59 AM] infected mushroom: Okay, I am confused now
On official docs it says
Actions are payloads of information that send data from your application to your store
| "use strict" | |
| const request = require('request') | |
| const fs = require('fs'); | |
| const zlib = require('zlib'); | |
| const opts = { | |
| url: "https://iptvx.one/epg/epg.xml.gz", | |
| headers: { | |
| "User-Agent": "request" | |
| } |
| #!/bin/sh | |
| echo "NVRAM and KEXT Cache Cleanup" | |
| sudo nvram -c | |
| sudo purge | |
| sync | |
This proposal is not longer active. Context: https://twitter.com/siddharthkp/status/909818777314902016
| class ControlledInputWithInternalState extends Component { | |
| constructor(props) { | |
| super(props); | |
| this.state = { | |
| isValid : true, | |
| value : props.value | |
| }; | |
| } | |