Release 0.6 – The Finale but not the end

Over the past eight months, I discovered a community in which I never thought existed. A community full of friendship, challenge, and hardship. I learned how to put my mind to the test and collaborate with individuals all over the world to reach one common goal. Improve and develop great software. opensource I’ve contributed to a variety of organizations like Mozilla, MoePlayer, Chart.js, and many more. I feel my contributions to the open source community have made excel as a software developer but tenfold as a problem solver. A lot of open source work is implementing efficient and unique problem-solving methodologies. You have to figure out how to not tackle a problem from one angle but several. You need to know how to dissect an issue to its barebone functionality and have the ambition to never give up even when the issue you are tackling is tough and shows no sign of remorse. This is what makes an individual an excellent open source developer and problem solver.

One thing to realize with open source is that you don’t know everything and it is likely that you don’t know nearly as much as you did about software or various coding languages. There will be projects that look like alien code even though you’ve been coding that language in college or university for three or fours years. This is when you discover the contrast of practical production code and the “simulated code” that you come across in coding classes that only aim to teach you a single or few concepts. It is important as a software developer to have exposure to real-world code as much as possible because this is what will prepare you for the workforce and future opportunities. Of course this not to say that simulated learning code provided by professors is bad and I do agree that it is crucial to help students learn the core concepts and application of different programming languages. I am rather stressing that some students tend to get into a cycle of being spoon fed code and explicit instructions how to complete a certain task. This is bad because in the workforce and in my personal work experience there is no project spec or sample code that dictates exactly how to accomplish the project. At my prior job I was simply told what was needed and had to design, develop, and test the software myself. So how does this all tie in with open source? Well, open source provides the means to work on real-world code with industry leading developers and gain valuable experience that you can place on your resume or use to better yourself as a developer. Taking this all into regard I decided to tackle a hard issue for my last release.

The issue I decided to tackle for this release was to add a calendar widget to the date filter for dejavu. In plain text it seems very simple to implement however I have very little experience with ReactJS and haven’t dived into state management and passing data from different parent and child components whilst using an external date API to return the correct data as well as conform to existing functionality in the project. Overall it seemed like a great way to challenge myself and I’ll walk through my development process. Luckily to start a maintainer of the project gave some good info on where to start as well as a good date picker API that fits perfectly with react called react-datetime. I began reading over the component that handles filter input called “SingleMenuItem.” Currently, in this component, we are using events to grab and validate text input instead of having the filter submit like an HTML form for example. This was a bit confusing for me and from my understanding, the input data is being stored in the components state and then accessed from a parent class called “FilterDropdown” which contains several “SingleMenuItem” components. The problem with this approach for me was having the react date picker conform to our existing functionality in the project which was very event focused. But as one knows from using a date picker widget most of the time you simply click on the date and it fills the field. Knowing this myself I assumed that the onClick() event could be used to trigger our existing input event functionality and decided to go down that route initially.

Example of dejavu events:

valChange = (e) => {
    var filterValue = e.currentTarget.value;
        filterValue: filterValue
// Further down in render()
 input id="{keyInput}" type="text" placeholder="enter value" onKeyUp={this.valChange}

(Chevrons removed to stop WordPress from processing input tag literally)

Essentially like shown in the example above I had to implement something similar but have it work for the react date time component. Now the date time component has an attribute call inputProps which can be used to dictate custom input properties for the date picker. So my first attempt was to add the onClick() event to the inputProps attribute but as a result, this canceled any onClick() event defined in the Datetime API thus making it run valChange with an undefined event. I ended trying almost every event that is offered in React and had countless hours of half-baked implementation where the user does some abstract event to trigger the function to grab the input value. I did consult one of the maintainers for the project about this issue and he was very helpful but I think the main problem with all the hours of testing and coding was my lack of experience with React applications.

Fast forward to my current implementation I needed to add three additional functions to SingleMenuItem.js because the  tag handles events different than a regular input (API reference) and returns date data in milliseconds (UNIX time) depending on the event which in this case is onBlur. So once onBlur is triggered we attempt to parse the date and set the filterValue accordingly. This logic happens in setDate. For range values, it is set a bit differently. I created two functions called setRangeStartand setRangeEnd which handle this use case. Depending on which one is set first (starting date or ending date) the function will either store the date in the dateStore state to be used by the contrasting function that will set the dates as the date range for filterValue.

—Code reference—


This is the implementation I decided to create a pull request with because I believed that it would work for all use cases. To my surprise, a maintainer got back to me and indicated that the date picker has to adapt to the date format of the data and thus be created dynamically basing its format on the data. This created a HUGE hurdle for me because it involved accessing information dynamically across objects that don’t have any relation. I have since replied to the maintainer asking if there is a way to access the elasticsearch data within a component that has no relation. I figure if I can access just one date I can base the format off that and create the date picker, however, the challenge is more accomplishing this in React with entry-level experience. I hope perform a quick update with the fix but overall I’ve enjoyed the challenge this issue has given me!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s