First of all I want to make it clear that this is just a showcase/demo product. It's definitely not something I'm planning to sell.
Additionally, it's not even remotely production ready, and it's missing about a zillion features that would make it a full-fledged project management software.
The main reason I built this was to have a good showcase for potential future clients.
The second reason was to share with the community. More specifically to show how to organize non-trivial React projects and to provide folks with a bunch of React code to learn from.
The third reason was to improve my skills and get better at working with hooks, TypeScript, and a couple of other things.
Back when I was learning React (4 years ago) I was a bit frustrated by the lack of non-trivial example projects. It was either a bunch of to-do lists, or hugely complex codebases like https://github.com/Automattic/wp-calypso.
I like to think that this Jira Clone presents a nice middle ground.
Fewer features sounds great. I personally loath Jira, and avoid using it whenever possible, but your clone looks really nice. You can improve 100x on Jira just by making it faster, simpler, and easier to use.
One suggestion: it looks too similar to Jira, you might want to change the design a bit so that Atlassian doesn't try to sue you or something.
IMO this "Jira clone" is way beyond the middle ground, it's way too complex for that. Might be a lot closer to a product than you think. ;)
For technology showcases the RealWorld example is pretty popular: https://github.com/gothinkster/realworld. Showcasing your tech prowess is quite a bit different, I get that.
Thanks for sharing! You've got some nice patterns and utils in that repo.
Random question: I noticed you switched from shorthand `<>, </>` to `React.Fragment` elements. Did you have a need to use keys somewhere and decided to update them all to be consistent? Just curious.
hey @oldboyFX, thank you very much for doing this. I really appreciate the effort and the fact that I can validate/calibrate my own skills looking at someone else's non-trivial codebase.
One of my pet theories is that if you are building a software engineering product, you should never write your own tools. You can't sell them, and you'll just be learning lessons completely unrelated to your product.
However; if you are building a software engineering culture, you should write as many of your own tools as you can get away with. Nothing builds culture like a shared unique experience.
I used it (Jira) for a short period of time a while back. I seem to recall that it's performance was highly influenced by non-obvious JVM parameters, and bits of the system would stall or crash without a clear pattern until a bit of trial & error with parameters solved it. It wasn't very "turn key" and the out-of-the-box config were... less than ideal. This was for a single user (me) so it's not like there was a much of a resource crunch.
We have 'macros' in https://www.cloudsynth.com to create issues on the various issue systems (jira/github/etc) and it it is actually pretty impressive how slow JIRA is compared to the rest of them. It's like theres a sleep loop or something.
First, this clone looks very nice and worth trying if your workflow fits it.
If this tool is still needing some feature you want, Do you run JIRA cloud? Jira by no means is perfect. It's one of the few tools that can handle complexity.
I noticed a huge leap in JIRA speed in switching from cloud hosted Jira to self-hosting.
On Cloud, Atlassian is mischievous and aggressively optimizes and constrains the resources.
If you don't use Jira often enough on cloud, it will be slow. The more it is used, the faster it gets.
One way to speed up JIRA Cloud is to hit the urls regularly with a script, keeps them cached.
I don’t think people like using JIRA in general, especially after companies bloat it with a number of useless plugins that only certain teams will use.
Really minor feedback, but I reacted almost viscerally negatively to the tickets "rotating" when you drag and drop them. Looks super unprofessional. The box-shadow and the basis of the interaction already made me know I was dragging it.
What motivated you to develop your own query and mutation hooks? Was there something unsatisfying with things like swr and react-query, or were you motivated to demonstrate/learn how to do it yourself?
Good to see someone working on this. Jira is awful but they have a strong enterprise hold with a bazillion switches.
It’s slow as hell and even the simplest things in their UX takes multiple clicks. Like resolving a ticket should be as simple as dragging it to done column but JIRA makes brings an additional popup for resolution type. Annoying UX like that.
Definitely a big opportunity to make a dent here.
Feedback: don’t use Atlassian JIRA’s screenshot on the main repo page. Have a screenshot of the UI you’ve actually built.
This is a great learning project for patterns & Best practices on so many aspects TypeORM, Hooks, React, NO-Redux ... as the Author mentioned already.
I am recently using a Next & Nest combination, Combining some of the good patterns of this project with Next&Nest combination would be great. Here is a good Next/NEST starter project https://github.com/saltyshiomix/ark
We are building a new issue tracker for software teams. https://linear.app
Especially making the UX feel fast, we since the slowness is really annoying in software that you use daily. The app built more like native client, caching the data locally and syncing the transactions the the background. That way it also supports offline use.
First, I wouldn't call it JIRA clone, because JIRA is a registered trademark by Atlassian and they might sue you for using it.
Second, I wouldn't call it JIRA clone because most people rightfully hate JIRA and at least to me your issue tracker seems to be simple, fast and user-centric, which is exactly what JIRA isn't.
I’ve found that keeping separate ‘package.json’ files in a client/ and server/ directory (and thus, having separate node_modules/ directories) leads to some annoying issues down the road.
I’ve heard that lerna[0] is maybe one tool that can help avoid this type of setup: does anyone have experience with this or recommend any other ways to organize separate dependency configurations within one mono-repo?
IME, using a single package.json is a harmful and naive practice, in abstract it results in a single product version and leads to poor separation between the client(s) and server(s) codebases.
It falls apart especially quickly when adding an iOS, TV (JS) or other client (or server) codebase.
To resolve the multiple node_module directories you can use tooling like Workspaces[0] (with both npm and yarn) which hoists the node_modules to a "workspace level".
I'd be interested in hearing other annoying issues you have with multiple package.json files.
Not sure if this is your project OP (can’t tell from a quick bio check) but if so, GREAT idea!
I love the idea of having an open-source showcase project to help with consulting client development. It’s awesome on multiple levels - shows potential clients how you think / how you work, gives a nice resource to those learning React, etc. etc.
Just a suggestion after skimming the README: the technologies something was built with are not its features. Features are the things the software can do for the end user.
Seriously are you and many commenters here missing the point? Author says several times this is not a product, it's a showcase of his skills as well as a reference codebase for people wanting to learn how to use ts/react/hooks/whatever in medium-size complexity project. The "features" here are technologies used.
Really great, I think something like style-dictionary, or similar token manager could help remove your use of magic numbers in your styles (padding: 13px, margin-top: 7px)
[+] [-] oldboyFX|6 years ago|reply
First of all I want to make it clear that this is just a showcase/demo product. It's definitely not something I'm planning to sell.
Additionally, it's not even remotely production ready, and it's missing about a zillion features that would make it a full-fledged project management software.
The main reason I built this was to have a good showcase for potential future clients.
The second reason was to share with the community. More specifically to show how to organize non-trivial React projects and to provide folks with a bunch of React code to learn from.
The third reason was to improve my skills and get better at working with hooks, TypeScript, and a couple of other things.
Back when I was learning React (4 years ago) I was a bit frustrated by the lack of non-trivial example projects. It was either a bunch of to-do lists, or hugely complex codebases like https://github.com/Automattic/wp-calypso.
I like to think that this Jira Clone presents a nice middle ground.
Bonus: Here's a Trello clone I built while learning React four years ago: https://boxd.ivorreic.com/ :)
[+] [-] brenden2|6 years ago|reply
One suggestion: it looks too similar to Jira, you might want to change the design a bit so that Atlassian doesn't try to sue you or something.
[+] [-] nohuhu|6 years ago|reply
For technology showcases the RealWorld example is pretty popular: https://github.com/gothinkster/realworld. Showcasing your tech prowess is quite a bit different, I get that.
Kudos for readable hook-based code. :)
[+] [-] pscanf|6 years ago|reply
[+] [-] pbreit|6 years ago|reply
[+] [-] Aperocky|6 years ago|reply
[+] [-] chrisweekly|6 years ago|reply
Random question: I noticed you switched from shorthand `<>, </>` to `React.Fragment` elements. Did you have a need to use keys somewhere and decided to update them all to be consistent? Just curious.
[+] [-] sandGorgon|6 years ago|reply
Just like Gitlab in early days. Please create a GitHub org around it and see if people want to contribute.
Only - brand it differently. Don't call it jira or clone. You'll be surprised on what a project can grow into if you paint the doors correctly.
Maybe call it Arij ;)
[+] [-] scrump3y|6 years ago|reply
[+] [-] gazelle21|6 years ago|reply
[deleted]
[+] [-] codemac|6 years ago|reply
However; if you are building a software engineering culture, you should write as many of your own tools as you can get away with. Nothing builds culture like a shared unique experience.
[+] [-] kiliankoe|6 years ago|reply
[+] [-] jadbox|6 years ago|reply
[+] [-] luckydata|6 years ago|reply
[+] [-] ineedasername|6 years ago|reply
[+] [-] parhamn|6 years ago|reply
[+] [-] j45|6 years ago|reply
If this tool is still needing some feature you want, Do you run JIRA cloud? Jira by no means is perfect. It's one of the few tools that can handle complexity.
I noticed a huge leap in JIRA speed in switching from cloud hosted Jira to self-hosting.
On Cloud, Atlassian is mischievous and aggressively optimizes and constrains the resources.
If you don't use Jira often enough on cloud, it will be slow. The more it is used, the faster it gets.
One way to speed up JIRA Cloud is to hit the urls regularly with a script, keeps them cached.
[+] [-] sandGorgon|6 years ago|reply
Brand it differently and build something really cool here
[+] [-] xyst|6 years ago|reply
[+] [-] macspoofing|6 years ago|reply
[+] [-] Aperocky|6 years ago|reply
And stop adding features unless 90% of customer demands it. Sometimes it’s worth it to tell other people: you don’t need this feature.
[+] [-] lxe|6 years ago|reply
[+] [-] dboreham|6 years ago|reply
[+] [-] nawgszy|6 years ago|reply
[+] [-] a_humean|6 years ago|reply
[+] [-] oldboyFX|6 years ago|reply
[+] [-] nojvek|6 years ago|reply
It’s slow as hell and even the simplest things in their UX takes multiple clicks. Like resolving a ticket should be as simple as dragging it to done column but JIRA makes brings an additional popup for resolution type. Annoying UX like that.
Definitely a big opportunity to make a dent here.
Feedback: don’t use Atlassian JIRA’s screenshot on the main repo page. Have a screenshot of the UI you’ve actually built.
[+] [-] LrnByTeach|6 years ago|reply
I am recently using a Next & Nest combination, Combining some of the good patterns of this project with Next&Nest combination would be great. Here is a good Next/NEST starter project https://github.com/saltyshiomix/ark
https://nestjs.com/
https://nextjs.org/
[+] [-] randomchars|6 years ago|reply
Unless it was changed since your comment: that is the UI, the project literally is a clone.
[+] [-] enra|6 years ago|reply
We are building a new issue tracker for software teams. https://linear.app
Especially making the UX feel fast, we since the slowness is really annoying in software that you use daily. The app built more like native client, caching the data locally and syncing the transactions the the background. That way it also supports offline use.
[+] [-] grezql|6 years ago|reply
[+] [-] btbuildem|6 years ago|reply
[+] [-] Scarbutt|6 years ago|reply
[+] [-] jupp0r|6 years ago|reply
First, I wouldn't call it JIRA clone, because JIRA is a registered trademark by Atlassian and they might sue you for using it.
Second, I wouldn't call it JIRA clone because most people rightfully hate JIRA and at least to me your issue tracker seems to be simple, fast and user-centric, which is exactly what JIRA isn't.
[+] [-] romellem|6 years ago|reply
I’ve heard that lerna[0] is maybe one tool that can help avoid this type of setup: does anyone have experience with this or recommend any other ways to organize separate dependency configurations within one mono-repo?
[0]: https://github.com/lerna/lerna
[+] [-] brod|6 years ago|reply
It falls apart especially quickly when adding an iOS, TV (JS) or other client (or server) codebase.
To resolve the multiple node_module directories you can use tooling like Workspaces[0] (with both npm and yarn) which hoists the node_modules to a "workspace level".
I'd be interested in hearing other annoying issues you have with multiple package.json files.
[0] https://yarnpkg.com/en/docs/workspaces/
[+] [-] nlh|6 years ago|reply
I love the idea of having an open-source showcase project to help with consulting client development. It’s awesome on multiple levels - shows potential clients how you think / how you work, gives a nice resource to those learning React, etc. etc.
Nicely done :)
[+] [-] nyxtom|6 years ago|reply
[+] [-] ooooak|6 years ago|reply
[+] [-] veeralpatel979|6 years ago|reply
[+] [-] gshdg|6 years ago|reply
[+] [-] mirekrusin|6 years ago|reply
[+] [-] rezz|6 years ago|reply
[+] [-] cow9|6 years ago|reply