c-hive / team-contribution-calendar Goto Github PK

Consider the mandatory/optional params that will be passed to the entry function.

• Mandatory params(check whether they're defined or not):

  • container(either an id or a class to the DOM element),
  • GH users(don't apply the full-width calendar restriction yet -> #9).

• Optional params:

  • CORS proxy URL,
  • GL users.

Tasks:

• restrict the mandatory params(abort the flow when something is either missing or presented in wrong format),
• handle optional params(default proxy URL, define GL users as an empty array).

At first, don't try to deal with complex things, just ensure that all of the params are in the appropriate form(unit tests should be included).

https://help.github.com/en/articles/about-github-package-registry

See:

• svg/svgo#1174

• team-contribution-calendar/package.json

  Lines 71 to 73 in 2541568

  	"resolutions": {
  	"svgo": "1.3.0"
  	},

Add a script (and possibly some code) so that when running npm run dev a local instance of TCC is served from source.

Add support for timeframes, i.e. certain user's contributions to be shown for only a certain timeframe, defined in days. The parameter must be optional, no breaking changes.

Document usage instructions for the minified version in dist in the readme. Keep the instruction simple and code example focused.

Also, think about renaming index.min.js to perhaps team-contribution-calendar.min.js.

Make sure that the first GH user's calendar is full-width.

Tasks:

• establish the same flow as before:
  • fetch / parse the user's calendar,
  • merge it into the actual calendar,
  • calculate the total contributions,
  • render to the screen,
  • OR log the error message to the console when the calendar doesn't meet with the requirement(and also abort the flow).
• copy-paste the Constraint part.

Our proxy didn't work with a test heroku deployment for some reason, but it should be the default.

Besides the JavaScript codes, the current distified version contains the imported resources at the top of the files. I'm not sure of the proper way of handling this case, but the idea might be to exclude these files and store them separately - as browserify provides roughly the same functionality.

Is anyone familiar with this topic? If so, it'd be great if one could leave some ideas/proposals. Either way, let's try to find the "conventionals" / best practices that are related to this particular case.

Let's see the outcome of this: flexdinesh/npm-module-boilerplate#5

AFAICT, the issue is that Babel relies on the browserlist entry to transpile the code to the target environment(s). IIRC, this was crucial to support evergreen browsers in dev environment(e.g. to transpile async/await, see #44). However, it's incompatible with our distifying flow(since we support the latest two versions of popular browsers, ES6 keywords aren't transpiled to ES5, that's why uglify-js complains about the const keyword).

Currently the whole process is vague to me, but one solution could be to separate the dev/parcel and prod/distify environments from each other.

When fetch fails there's an exception and the loading spinner is stuck. Instead, it should be handled gracefully and it should not remain in a loading state.

Prepare the whole structure for the future changes.

Tasks:

• basic NPM structure based on the conventionals/observations,
• prepublishOnly hook along with the related scripts,
• testing environment(Mocha and Chai, test coverage),
• CI/CD setup on Travis(refresh dist folder -> automate commit/push to the master branch).

Our default CORS proxy server is forbidden for some reason.

Perhaps GitHub denies the requests specifically from our server as TCC works fine with my self-hosted server.

As it doesn't reflect the latest state. Use a similar gif.

Depends on #56.

vs

There used to be some space if you look at the picture in the readme.

As we discuss c-hive/dotdev#76 (comment) , we could improve the calendar to a more flexible component, if apply these css rules to the .container:

min-width: 415px;
max-width: 800px;
width: 58%;

Figure out the way of displaying the pre-prepared basic/empty calendar in pure JS. The flow might be changed depending on #1.

Tasks:

• render the calendar into the previously passed container(elly might be useful in this case).
• apply the same styles as before(paddings, margins and text-alignments).

At this point, we should do integration testing so that examine whether the features work as expected or not. Test the project locally as:

• an NPM package,
• a CDN link.

Depends on #25, #24, #18

Publish package to npm.

Acceptance criteria: works on c-hive.dev from npm. Follow semantic versioning. Start with v0.1.0. If AC is successful bump version to stable v1.0.0.

There're some existing fetch is not defined errors that appear during running the tests. Not sure about the exact reason for this behavior but the errors are coming from the cases in which the async calendars fetching are being tested(aggregateUserCalendars). Interestingly enough, the functions have already been mocked in these cases - that's why I don't really understand why it'd like to use fetch(it somehow reaches the implementation of the related function instead of returning the defined value in these cases):

getJsonFormattedCalendarAsyncStub = sandbox.stub(GitHubUtils, 'getJsonFormattedCalendarAsync').returns(gitHubUserJsonCalendar);

Obviously, mocha doesn't provide the built-in fetch as it runs under NodeJS, but this still doesn't answer/solve the question of this unexpected behavior.

Add support for nightly mode.

IMO the "stutter" of loading the first user doesn't look great. Let's do the following:

• predefine an initial user with no data and the right calendar setting (this will also hide the issue of calendar sizes from the users) -> resolved by #11.
• keep the loading indicator running until the first async user is loaded -> resolved by #14.

See: c-hive/guides#8

• Note how our squares are not as sharp as GH's (might be caused by #37)

vs

• GH uses bigger text for the X contributions in the last year text which we could also follow

• GH uses more grey text colos for the colum/row names and less/more text which we could also follow

• spinner resets during loading (possibly related to loading the first user separately)

I find this scrolling bug:

The issue has already been discussed in the other repo.

The list might be extended with other requirements along the way. We can even "steal" some ideas from this repo.

I have digged deeper and read a couple of articles about the different ways of structuring/building npm packages. At first, I'd establish a simple boilerplate that comprises the elements below:

• BABEL

  • To convert ES6 features into ES5 - the reason for using Babel is that not all the browsers support the ES6 features yet.
  • It seems that the pattern is to store the ES6 and ES5 codes separately - and only expose the latter one.
  • We'll definitely need a flow that is strongly similar to this example.

• TESTING ENVIRONMENT

  • The best choice might be to work with Mocha - along with Chai? - as we'll test native JavaScript functions.
  • And also don't forget to add test coveragement.

• ESLINT

  • The same applies here similarly to all of the other projects.

• PACKAGE.JSON

  • The production/development level dependencies should be considered.
  • Shall we define peerDependencies? I don't think so.

• .NPMIGNORE

  • In order to ignore the files that shouldn't be included during the installation of the package(for example configuration files that are related to development, etc.).

• STRUCTURE

  • Besides the configuration/specific files above, a pretty simple structure is required that:
    • exposes the main interface via the index.js file,
    • contains an empty lib/src folder in which the utility functions will be defined along with their tests,
    • demonstrates that the testing environment works.

• ADDITIONALS

  • It's good to keep in mind the following commands:
    • npm link and npm pack.
  • CI/CD, PRE-HOOK

Any other ideas/proposals are welcome.

Noticed that on one deployment the contributions are misaligned. Let's verify if this is a bug with the latest version.

Follow-up of #40.

(1) The "X contributions in the last year" message doesn't respect timeframes(i.e. it always displays the contributions from a full-year perspective).

(2) The timeframe's to field isn't accurate, i.e. it goes a few days back compared to the date it's given. E.g. when it's set to 2019-09-02 it goes back to 2019-09-01:

It's something that didn't turn out while working on this feature for some reason. My gut feeling is that the way we're "playing" with the dates causes this inaccuracy. We may switch to moment for a more precise date comparison rather than relying on the built-in Date() object.

Ran into a few things when setting up another npm project which could be implemented here as well:

• .editorconfig
• vscode workspace settings for prettier autoformatting
• prettier and related eslint dev dependencies
• .eslintrc.js rules and prettier plugin
• cross-env

See:

• https://github.com/c-hive/x-rate-limiter/commit/5dd80a5a07a764086d354521afee333a71b0380f
• https://github.com/c-hive/x-rate-limiter/commit/f13fa92515e470490f20147205b11799c6d8c179

And a question: why did you need to explicitly require a file in the test script? --require ./src/utils/TestUtils/mockNonJsResources.js

Accomplish the same hover text effect that GH provides.

@thisismydesign has already described the requirements in the other repo:

• no effect on the tile,
• transparent message bubble,
• text like N contributions on <date>.

This way it will blend better with sites that have a different background.

Started in https://github.com/c-hive/team-contribution-calendar/pull/52/files

TODO:

• find or create action in actions to make a commit
  • input: pattern of files to git add, commit message
  • if a new action needs to be created i recommend to use a native JS action with octokit. you authenticate using a github token (which is part of the secret store by default) as seen here: https://github.com/babel/actions/blob/master/trigger-github-release/release.js (i think octokit can commit but i didn't check for sure)
• release to NPM, there should be an official action already available for this

• Basic setup(#5, resolved by #2 and #3).
• Elaborate the entry point(#6, resolved by #8).
• Session: integration testing, presented by @thisismydesign. :)
• Empty calendar, styles(#7, resolved by #10).
• Pre-define an empty user(#1, resolved by #11 and #14).
• Handle GH / GL users(#12, resolved by #13, #14 and #16).
• Hover effect(#18, resolved by #23).

Implement the same flow as before. The idea would be to create a class that comprises the following fields:

• actualCalendar,
• totalContributions,
• isLoading.

The class behaves as an actual state and exposes getters/setters so that:

• update the fields based on the received data,
• get the current values.

Tasks:

• establish the "global" state,
• GH / GL integration.

As a part of the GH integration, don't forget to implement the remaining task in #1(loading indicator).