Closed Chalarangelo closed 4 years ago
From @skatcat31 on September 11, 2018 5:31
You should add Modals as they're extremely helpful to have a dynamic modal that closes on click away from the child
From @skatcat31 on September 18, 2018 15:45
Spread notation is something that's well documented and used in few places, but has definate hlepful places(styles are a big one), and controlled versus uncontrolled input is a huge contention point in React, so it'd be smart to touch base on it. It's something I don't really think about myself since the coding guidelines I implemented enforced controlled at my last job(considered a best practice to guard against injection and cross site)
From @skatcat31 on September 18, 2018 15:46
As for organization I think a separate folder or project would be best here. Also to note about Modal is that there are full screen modals based on events, and middle man modals based on parent container. Both would be helpful since I've found more pages struggling with modals.
Update: Having tested subdomain support on Github pages, I have to report we need to move React snippets into their own repo, as it's the only feasible way to host them under react.30secondsofcode.org
. Probably a good idea, too, as it will help with separation of concerns. Only issue there is that star count will not be shared, but that's probably alright.
In light of this, I think we should close the issue and go on ahead to create a new repo over the weekend to get started. What do you guys say?
From @fejes713 on September 27, 2018 15:51
Better idea to me honestly.
30code should stay 30code and provide snippets for vanilla JS only.
30react is a great idea, for the very start, I don't think we need a lot of snippets. Let's keep the focus on quality. If you're up to, we can develop under private repo and then make it public (for the big reveal π―)
@fejes713 We can't do private repo on org without paying, plus I wanted this to be a good starting point for Hacktoberfest participation, I will make a new repo and see if I can migrate the issue over to it.
From @fejes713 on September 27, 2018 16:17
Idea was to make it under user private repo, but as you said Hacktoberfest is here very soon, so we should give people opportunity to make something great!
Seems like a great place to start. I'm going to be busy the next few weeks but we should at least get a handle seated on how we want to display these and organize content soon
@Chalarangelo
Some of suggestions that I want to share:
Hey! @Chalarangelo I am really looking forward to contributing to this repo. In what format do I submit the snippets?
For example, for show/hide component
, should the snippet contain the entire class or just the part that is necessary?
We are not set on a snippet template just yet. If you have any template suggestions, you can check #4.
From @ShawnToubeau on September 18, 2018 13:56
Hello! Hope you don't mind me adding to this list :)
Noticed a handful of posts asking about React-Router, would that be something you would want to focus on as well?
I am not sure that React Router should be added honestly. They have a very great website already displaying a lot of basic and straight-to-the-point examples. Would be redundant in my opinion.
I am not sure that React Router should be added honestly. They have a very great website already displaying a lot of basic and straight-to-the-point examples. Would be redundant in my opinion.
They do, but people often get implementation wrong(especially with redux in the mix). I would suggest that we consider it, but for initial release or scope it can easily be left out(get examples out first and decide if we want to include routers later option)
Yep, I agree with what @skatcat31 said. Let's go for basic snippets first, then see if we want to add router or anything else.
Hey @Chalarangelo and @fejes713, great work on starting this repo and this issue!
I have an idea suggestion for a code snippet, how to setState
based on the previous state. This is the case where I see most of the people do the wrong thing:
// bad
this.setState({ counter: this.state.counter + 1 })
// good
this.setState(prevState => ({ counter: prevState.counter + 1 }))
It's also what ESLint suggests you do if you try the bad practice in your code :) There's also an explanation in React docs https://reactjs.org/docs/react-component.html#setstate
Let me know what you think and whether it should be added :)
@nikolalsvk That sounds like a useful snippet in general, at least to me.
It's something I often have to correct junior developers on. Good catch.
@nikolalsvk Definitely a good addition to our collection. Thanks a ton for stopping by to help us! π
@Chalarangelo any plans on when do you want us to start implementing those? What's our current progress with the template?
Current warning: I have had an extreme amount of interviews this week, and will for the next two on top of moving. I'll help when available but it's looking that that's going to be sparse. A lot of the commenting I'm doing is on scattered access to the internet(has been for awhile... I really just want a consistent schedule again -.-)
@fejes713 Maybe start around October, 15 or something like that? Just to have enough time to decide on a template and figure out everything else. These won't take extremely long anyways.
If anyone wants to start implementing snippets without a template, feel free to do so, we can reformat them later.
@skatcat31 Good luck on interviews, hopefully, at least one of them will be bingo π
@Chalarangelo Right, I'll try dedicating time around 15th Oct for this π
@Chalarangelo Do you have a place where snippets can be written and reviewed?
@SCHKN I suppose we do not have the exact template for React snippets jet. I would suggest to wait a bit and see what we come up with (less work then - no reformating).
Once there is a template we will have ../snippets
folder where we will store snippetName.md
files. In there you can PR snippets that you've written.
Hopefully this makes sense π
TLDR: by waiting for template to be discussed we won't need to reformat each snippet. Less work = better
possible help with snippet names: We may want to "name space" them with snippetName.class.md
or snippetName.function.md
or to tag them in the snippet somehow so we can put them into categories of classes or functional components. This way we have an extra layer of organization and it's obvious before even opening the file, or once open, what type of component it is without reading source code.
Maybe we don't need to have show full components in our snippets π€
We can only share relevant idea in the snippet, and make it inputtable (copyable) in any component you like. That's how React docs work and how basically every React library on NPM writes their examples :)
Then, we could put examples of the snippet in the expandable "+ Examples" container like it's done in the 30-seconds-of-code website :)
Also, I think the main purpose of these cards is not to make them as copy-friendly as they can be, but to learn something from reading them. And by adding so much code at first (like component, defaultProps, constructor), it won't be readable for 30 seconds anymore π
What do y'all think?
I think examples could be made to work in separate codepens or repls either inside the page or opening in new tab, so we can isolate them from the main website code.
I really like the format that @nikolalsvk suggested. I am voting +1 for this. By doing so we will still have a clean and understandable format that provides high value to the end user.
@skatcat31 @atomiks @flxwu could you please give your final opinion on this issue so we can slowly start working on this repository π
showing relevant parts is definitely a good idea, but it means we'll basically always need a helping post about how our code is organized and what parts are where and such... But either way it should still probably be organized as "things in constructor", "methods", etc. and have some sort of common order to snippets.
So it's not a bad idea, but it means we'll basically always need a "help" post at the top
"Help" post would be awesome to have, to explain the structure of the cards :)
Plus, it's not a big deal to implement a help box at each page of the future website with nowdays compilers of Markdown files.
Note: Reviewing the suggested snippets, I can see that many of those suggestions are not exactly things that we want to provide as components, but rather concepts we want to show off in components that we want to implement. Therefore, we still need a few suggestions for snippets, so we can find a way to integrate those concepts into new components.
Yes I agree @Chalarangelo . Some of those are/could be part of a component. Some of them might be useful as a component.
The concepts can also be mulit-categorized in future as this project expands i.e. fall in one or more than one domain. Examples like those additional domains would be - redux, react-router, formik, PropTypes and much more.
So we would need those domains to interact with this project which provides information about only "React.js"(framework's perspective)
Also newbies would follow the patterns that we have incorporated here. Therefore we also need to stick to the specific patterns for concepts and components. There are also advanced patterns and I have one good example - https://github.com/manjula91/react-advanced-patterns
Redux, React-Redux and React-Router should ideally be part of the same repo as React. Same applies to PropTypes. The rest of the tools are probably out of scope for this particular project and should be explored later down the line. However, currently, we are focusing on simple React snippets to get things right first, before expanding and combining with other tools.
So we should decide on a final snippet structure so we can start applying it to the currently suggested snippets. I've been reviewing a few but my time has been limited due to the interview process.
Whatβs the status on this? I can contribute and need to know the snippet format.
@jonniespratley the format is the one described on the snippet template file (or you can take a look at existing snippets, as well).
Hey @Chalarangelo @skatcat31 I wanted to contribute in this. Can you please tell me how to make my contribution in this awesome library?
Hey @Chalarangelo @skatcat31 I wanted to contribute in this. Can you please tell me how to make my contribution in this awesome library?
You can have a look at the Issues. You can mainly contribute snippets or there are other "Chores"
I'm going to add another chore for Contributing Guidelines
. Currently I'm on boarding at work, so maybe in a few weeks I can circle back around to this after I get unemployment and insurance figured.
I think there are projects/products which are built using older versions(still using older versions like 15.6 or 16.0) like some would not support new Context API or some would be using deprecated lifecycles hence making it legacy code.
So there should be line added in snippet.md stating which versions or above versions this snippet can be used
@meetzaveri that's a good point. Totally agree.
I was reading a few articles about clean code and code reusability. After semi-intensive research, I still believe that we should use prop types and default props. Yes, it will make the card longer but user shouldn't try to guess the props or look into the code itself - bad habits.
Remeber 30s of code? You just copy paste the snippet and it works. If we don't follow this approach with 30s of react somebody will copy it without any props and get error. Think about development experience and robustness of the snippet. The goal is to build reusable components, not the halfway done snippet just to say we did something.
Think about it few times; let's go for quality not quantity. @skatcat31 @Chalarangelo @meetzaveri
@fejes713 the general issue with default props is that some things cannot be set to sensible defaults (e.g. content of components). I'm not against this, I'm just trying to figure out what the best course of action is.
@fejes713 That's why I say any defaults should be assigned in the constructor. Default props, while useful, is still awkward in that it's not actually on the class, and makes copy pasta harder because you have to remember to look for other things too. I'm a big fan of JS classes keeping instantiations to the constructor(hence my gripe with field proposal)
Hi @Chalarangelo , first-timer here. This is an awesome repo and I am looking to contribute to this repo! I'm interested in one of these: lazy loading component, notifications, or hamburger menu. I'm already read the contributing guidelines mentioned above. Can you tell me which one you recommend more and the details that you are trying to achieve? Thanks!
Hey @theodorusyoga, thanks for willing to help us! We're glad that you like the project π
We're trying to make a collection of useful components that you can integrate to your own project and use for learning purposes.
Pick whatever component you feel most comfortable writing and I'll be happy to help out and review your PR.
Let me know if you need any help.
This issue is a bit of a mess right now, I'm closing it but we can still add snippets suggested here in new PRs.
From @Chalarangelo on September 10, 2018 20:37
After some internal discussion and the idea floating around for a bit, I think we should go ahead and brainstorm a bit about adding React snippets in the repository, as a separate page, folder etc.
The idea is to provide a basic cheatsheet for React, much like the base repository, except this will be a sub-project (as it is part of the JS ecosystem and we are probably not going to have snippets in the hundreds in this category). I've started compiling a list of popular StackOverflow questions and answers that might prove useful. Add your suggestions below and let's get a decently-sized list ready for October, when Hacktoberfest starts and we can expect a decent flow of PRs.
My completely incomplete list of ideas
Collapse #11Rating #12Tooltip #22Modal dialog #17Array.map()
to create a row in a table (or similar) / SO question #9 and #26Array.map()
to render a list #8Toggle #20Autolink (convert link from text to actual<a>
element with link) #27Tabs #38Carousel #23Drop area file uploader #41Tree view #43Timer / Clock / Countdown #33Slider 8dfdcfdAccordion c0177c0My completely incomplete list of ideas (old)
componentDidMount
/ SO QuestiononClick
event with arrow functions / SO QuestionshouldComponentUpdate
for component, if we have a good example for that / SO Questionselected <select>
/ SO QuestionmapDispatchToProps
/ SO Questionthis.setState
, too many people ask this / SO QuestionsetState
with dynamic key name / SO QuestionpropTypes
of nested object / SO Question -setState
with nested objects / SO Questionupdate
immutability helper / SO Question<script>
via React / SO QuestionpropTypes
/ SO Question:hover
styles / SO QuestionsetState
based on previous state / CommentCopied from original issue: 30-seconds/30-seconds-of-code#739