Show HN: A React.js yearly calendar component | Hacker News Reader

Show HN: A React.js yearly calendar component

github.com

94 pointsGiovanniFrigo48 comments

That's an interesting way of showing a calendar. Is this common practice? I've never seen this before. I think the only yearly calendar I've seen more often lately is the one used on the GitHub profiles (here's a d3 one: http://bl.ocks.org/mbostock/4063318).

I've seen this style used in traditional wall calendars, usually with just that month's line on the bottom, but sometimes with previous/next month lines too.

I once created a ColdFusion (anyone remember CFML?) module for rendering similar calendar layout on server side.

It's definitely not common, but sometimes it's useful to have the whole year under your eyes.

Basically we needed it for a project where we had to display how an year was subdivided into 4 different periods. Here we also highlighted the working, festive and prefestive days.

I think it turned out to be an interesting layout, you can see it here: http://postimg.org/image/4yqaywm2r/.

I've hardcoded this kind of calendar in a lot of hotel backends (to fill availability) but I suspect they are useful for any season related form.

Yeah that's another interesting use case! Maybe I'll add the "select period" feature, thanks for the idea!

100 ms delay on every click (measured in Chrome's Profiles tab). I'm on a 2013 MBP. Seems a bit too much for making a number bold.

Any idea on how one could optimize the rendering function to reduce this lag (which BTW I can barely see on my 2015 MBP)?

Cacheing? You're doing a lot of work in render that could be computed once. Try saving a few years +/- into state on componentDidMount. And for day clicks, pull rows that arn't touched from the cache.

Will surely do, thanks! Also, how did you test the onClick delay? by spamming timestamps in the code? :D

Use the Chrome's "Profiles" tab in DevTools.

No, you open up the Chrome Dev Tools, click the Timeline tab and then start recording. Click a few days in the calendar, stop the recording and then you'll see that after each click it takes 100ms until paint events are shown.

Things would also be significantly sped up if you compiled in production mode. From looking at your source, all the dev mode checks are still being performed. See:

https://facebook.github.io/react/downloads.html (the note under npm section)

https://github.com/facebook/react/issues/1772

http://stackoverflow.com/questions/22118915/how-to-turn-on-o...

Thanks! Useful links, I didn't know anything about this. Will surely start using the `NODE_ENV=production` environment variable from now on!

That reduced the click delay from approx 90ms to 67ms, that's a pretty solid -25% there! Thanks for the suggestion, @jkkramer!

One common optimization is to strategically use shouldComponentUpdate to limit the number of components that render each time the state changes. In this case you could create a Month component which renders a single <tr> element. This component would then implement shouldComponentUpdate to check if the state used to render that month has changed. If not, shouldComponentUpdate returns false and the month does not re-render. This means that clicking on a Day should re-render two Months at most.

The same shouldComponentUpdate optimization could be added to both Calendar and Day, but in this case clicking a Day would always require the Calendar to re-render, and running through 365 shouldComponentUpdate functions (returning false from at least 363 of them) without first limiting by Month would not be ideal.

If the state is managed with ImmutableJS or a similar library, shouldComponentUpdate would only have to do a single reference equality check. Either way you should see a big improvement from any implementation that allows the individual Month components to skip rendering:

http://facebook.github.io/react/docs/advanced-performance.ht...

Great! thanks for the explanation and the docs!

Delay is 50ms on my MBP. Here is a profile: http://i.imgur.com/ty11Utl.png

With the main bottleneck being here: https://github.com/BelkaLab/react-yearly-calendar/blob/maste...

Implementing a good shouldComponentUpdate() should fix it.

I'd like to see an option to move the start of the week (first column and bolded column) to Monday (for those of us who prefer w/c monday).

I'll have a go myself when I get home, if I'm successful I'll submit a pull request.

Great! yeah that was definitely something I wanted to add, here in Italy we usually use Monday as week start.

Feel free to submit a pull request then! I just kindly ask you if you could use airbnb's Javascript and React style guides, that is a pretty good standard IMHO https://github.com/airbnb/javascript/tree/master/react

Sorry for asking this here, but I'm trying wrap my head around React. With the fact that we want to isolate styles for each component, how do we go about theming the components later on?

I suggest you to read this (http://stackoverflow.com/a/31638988/2304450) very good stack overflow answer, you'll find some interesting introduction to inline styles if that's what you were looking for.

A different approach could be to pass a `classScope` string props down to the components, and each component then applies it to the classes it uses (Example: return (<div className={this.props.classScope + "inner-div"}></div>); ). This way we could achieve better css selector scoping, at a cost of a slightly more verbose code when using a component.

Also, you can get way more competent answers on reddit (/r/reactjs) or on stackoverflow :)

If you are using something like browserify you could create a module that defines the variables you want to use for theming or something and then import that module to achieve change once/ show everywhere.

You could also just not do inline styles, it isn't required.

You might consider some people won't be able to use this calendar as-is; it isn't accessible. Consider http://www.456bereastreet.com/archive/201302/making_elements... and perhaps change the spans to native HTML elements with visual and keyboard focus. Thanks for sharing!

Thanks for the suggestion! will surely look into making it more accessible!

I'm confused.

1. This is a fork from Hanse Kristian, who doesn't appear to work for your company. That is, it doesn't look like BelkaLab did anything but change package.json to name itself as the author.

2. It's a bit confusing why you put the generated demo.js file as part of the repository and have npm (.npmignore) ignore the src files. Is there something special about this demo.js file instead of it being browserify output?

Thanks. Really useful and you save me a lot of time! If I found some problem I'll contact you ;)

Please do! Also if you have any feature request use github's issues to let me know!

Nice work!!.

Side comment: I was expecting some sort of a 'marketplace' to emerge for react components. I am surprised by so few reusable react components.

check out http://react-components.com, they have a nice collection there!

Also: https://react.parts/

Wow, very useful. I'm going to use it for sure.

Cool! If you find any bug or have any feature request please open an issue on github!

Is that really worth showing to HN? I mean, I dont want to be rude -- your code is ok, no problem here -- but it's not even a library, it is just a widget in 200 LOC, that renders a single table. What's the achievement here?

imho, this is worth showing as a piece of design.

Its an innovative calendar layout and while I don't know if I would use it in time / data selection, in terms of visualizing data inside of a year it has a lot of potential.

You definitely won't use this for date selection, but we found it useful to layout the whole year and to review it at a glance.

Thanks for your kind words anyway! :)

I liked the layout. The main take away for me was the <today> in Red. It may be a trivial feature,but with so many widgets pounding my eye, it was nice to zoom in to todays date. I can see master planners (in inventory world) sticking with this layout, though I am sure you guys must have already done your market research.

No market research here, TBH! It is a component extracted from a project we did with our agency Belka, but we'd love if people start using it in other projects!

Is that comment really worth sharing on HN? I mean, I don't want to be rude - the English is ok, no problem here - but it's not useful at all, it's just complaining about a thing upvoted by 50 people. What's the purpose here?

I can tell from your own previous submissions that you are somehow affiliated with "belka.us", same company that open-sourced this calendar widget, so I am sure you were first here to upvote, and I understand why you are being so passive-aggresive now. But I really do not want HN to be a platform for such kind of self-promotion.

Yeah, we are belka.us and we are not ashamed of doing self-promotion here.

I don't see what's wrong here: every company in the IT world releases open source components: Django, Bootstrap, Foundation and React itself are open source projects backed by companies. But there's also smaller things being released every day, and each of them contributes to the great world of open source.

We use open source, we give back to the open source community. We are giving away our time for free releasing a component, I don't see anything bad adding a small link to our website.

You're doing fine; thanks for sharing!

Such kind of comment is also in very poor taste - it offers very little substance, and mainly aims at going in a roundabout way to belittle the comment it is responding to without offering a concrete solid argument against it.

And that is even without that contextual information that you've noted.

It's a "Show HN" article. From the "Show HN" rules:

> Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.

https://news.ycombinator.com/showhn.html

There is nothing even remotely inappropriate being done here, except for your comment, which violates the self-same rules:

> Be respectful. Anyone sharing work is making a contribution, however modest.

So when you'll find yourself looking at front page full of "woo look at my helloworld app btw here's our website"-like posts, would you still think the same? Every tolerance should have its limits.

Unlikely, but considering we have a Show HN section that is specifically intended for that, which garners its own interest, and competes against the other, non-Show articles for front page space, if the front page were filled with Show HN content, it would either be due to a slow news day, or because people were cranking out worthwhile-enough apps to merit front page supremacy.

Either way, your parade of horribles is unlikely to occur, or be that horrible if it were. To each their own though.

Yeah, that's a component, no more, no less.

I just wanted to share this, I think some people disagree with you if I am in homepage right now

Says the guy with 0 submissions and a handful of comments in a 2.5 year old HN account...

Reply on news.ycombinator.com