-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time Ago from a different time besides Date.now #45
Comments
@joshrowley This is an interesting idea that basically no one has ever asked for. My basic philosophy with react-timeago is that I'm happy to add new features as long as people who don't want that feature don't have to pay for it. This is why language support was added with custom formatter functions that are imported separately. If you have an idea like that I'm all for it. But before that happens, here's a few things to consider:
Any other ideas? |
@nmn There should be an option to use a static time that we can pass in as a prop instead of Date.now() for the initial render, but it can use Date.now() on subsequent updates. The reason for this is that React-timeago is being used for server side rendering but because of the way that it uses Date.now() I will always end up with Invalid checksum with server-side rendering I believe React-timeago should support this use case for better integration with React |
Hey @nmn , I was able to use the |
@allenylzhou I like this solution the best so far: Ask for an initial render string which is static. Use This way, the server-side render and the first render of the client-side will match up. (It'll just be a static string). But after that it will become a dynamic component again. That said, this behaviour can be put in a container component. I'll add that container component as an optional file you can use from the package, but in the mean time you can do it your self. class staticContainer extends React.Component {
state = {mounted: false}
componentDidMount () { this.setState({mounted: true}) }
render () {
const {children, ...props} = this.props
if (!this.state.mounted) {
return <span>{children}</span>
}
return <TimeAgo {...props} />
}
} @joshrowley This might be a better solution for you too. |
Another use case for this is for Jest testing - if you snapshot a component with a TimeAgo, subsequent tests will have a different Date.now and fail. One solution is to mock Date.now itself, but it may have unintended side effects. |
This feature was added and released. You can now override a the 'now' prop. |
Hi! Great library here. I'm wondering if there's any interest in adding a feature to allow you to specify a different way to calculate the current time besides using
Date.now
The use case is that I want to display time ago, but I do not trust the client's clock and instead send a timestamp from my server, compare that to the client's time, and then use that to calculate a consistent offset that I use to calculate the time ago. I rolled this myself but I'd love to replace with a open source component.
I'll probably still fork this and add it for my own usage, just throwing it out there to see what the maintainers of this package would think about it and whether it'd be a good PR / open source contribution candidate. Thanks for your time and energy!! 😄
The text was updated successfully, but these errors were encountered: