So, I've created a component library in React.js using Typescript. I'm using Tailwind CSS on this component library. I've published the component library on npm and then installed it on a website that I'm building. I'm trying to use Tailwind on my website as well. The problem is that when I apply Tailwind to the website and use the components, it is applying Tailwind to the component library a second time. Tailwind was already applied once to the component library when I built it. Now it is applying it a second time, and it's screwing things up like my sizing breakpoints. Here's an example of it being double applied to a component in my component library: See Here. How do I get Tailwind to ignore and not apply itself to my component library?
My initial idea was to see if there was a way to modify the css class names on build, but I haven't found any information on how to do that. Any ideas on how to fix this are appreciated.
it would be best if you had a prefix set up in your website tailwind config to avoid collision between your components library and website.
I came across this article on Codrops about altering the scroll behaviour with smooth easing:
https://tympanus.net/Tutorials/SmoothScrollAnimations/
Here is the js file responsible for this subtle effect:
https://github.com/codrops/SmoothScrollAnimations/blob/master/js/demo.js
I would like to learn how to turn this class based oop syntax from vanilla javascript to React.
I already figured out that some custom hooks can comes in handy (useWindowsSize or useOnscroll) but I can't figured out the way to pass all other class related stuff into a stateless functional component structure.
I know that this is Scrolljacking and it is not supposed to be used in a webpage, but I'm trying to learn how to completely switch to react for my projects.
My question is, how would you refactor this code?
(p.s. I'm not looking for someone to do the job for me. I'm just looking for advice on what is the right way to face this challenge, as now I'm stuck not knowing where to start.)
I'm looking to build a UI with stackable cards, something like:
Where there are a dynamic number of cards being the currently active card, and as the top card goes away, cards below is displayed. Very similar to Tinder's swipe-able experience.
I need to build this UI Component in my React web-app (not native). I found this library which looks very popular:
https://github.com/oliviertassinari/react-swipeable-views
However this library does not appear to support stacking view, and showing all the views at an offset as seen below.
Does anyone know if it is possible to accomplish what I'm looking for with react-swipeable-views or if there is a better library out there to accomplish UIC as seen in the image?
You could use the react-spring library to achieve this. Here is an example of that behavior implemented.
I hope it helps you!
I'm learning React.
It seems React highly promotes composition. Create React App even advises against reuse of css class.
Let's say I have a container, which is a white box, with nice rounded corner and shadow, etc. It can contain anything. That's it. No logic. Not much html except a <div>
Traditionally, I would just create a global css class named .white-box and then apply it to any <div> that I want it to be this white box.
I know in React you can do this, too. You can do whatever you want. But what is the general practice? From what I found online, it seems I should create a component for it and put any children inside:
<WhiteBox>
<div>anything</div>
</WhiteBox>
Isn't it overkill? What are the benefits of doing this? Should I create a component for everything that can be re-used, even when it is such a small thing?
This is honestly a matter of personal preference and experience.
For example, the seemingly pragmatic way would be to use a .white-box class on a div; it's super easy and requires no imports!
A bit later down the line, you decide that every white box inside some other control needs a bit more shadow, so you go and add a CSS rule for .some-component .white-box, and bam, now you got a shadow'ier white box without messing with the original CSS class. Nice and easy!
The problem with that is that when you do it once or twice, it's fine. But you'll soon develop a habit for "patching" the class name rules for specific purposes, and before you know it you're mixing rules without knowing it yourself, which is exactly what it says on the tin: Cascading Style Sheets.
I've been there myself, and it's no fun to maintain. Now I create components for everything, even things as simple as a white box. The trick is to name them right; you wouldn't call it WhiteBox because if you change the color of the box down the line, the rest of your code is a lie. ;) Instead, call it something like ContentBox; something that describes it's purpose, not what it looks like. Then use props to determine what characteristics the box should have:
<ContentBox shadow padded rounded>Awesome</ContentBox>
I'm personally a big fan of CSS Modules because they make sure that class rules never clash which avoids the issue outlined above entirely. Instead, if you want a class to inherit some styles from another, CSS Modules lets you compose them together.
Example CSS modules file:
.root {
background-color: #fff;
}
And a React component:
import React from 'react'
import styles from './ContentBox.css'
export default function ContentBox({ children }) {
return (
<div className={styles.root}>{children}</div>
)
}
The actual classname being used is actually something like ContentBox__root_abcd123random so even if you have another CSS file with the same .root class, the rules never clash.
An added bonus of doing it this way is that your components are now portable to other projects because it only depends on styling within the CSS file that ships with the component. I've enjoyed great reuse using this strategy across many internal web apps at our company.
That's right. It's not overkill when you are confident that features will be the same across your app. For example, you can have the nice shadow styles as you said, or guarantee that all containers have white background or might have a fluid prop which will expand the element for the whole parent width.
In fact, there are React frameworks like Semantic UI React that do exactly like this.
Every time you see yourself designing some HTML that should be consistent in your codebase, that should ring a bell for creating a single unique component for it. And if you think your components are big enough, maybe you should break them down.
This approach makes your code easy to test, once it's way more easier to test small stuff with limited and well-defined functionalities than a big component which several features. Once you glue them together, because of React one-way data flow approach, you know exactly why stuff is not working - you now have simple components for each feature, and if they are not working as expected, there is only one flow where data might have came.
As a beginner those concepts might be hard to grasp. But once you start digging into large codebases and projects, you will see how "modularizing" your application will have long-term benefits.
I've seen this image slider on the front page of http://www.ibm.com/us/en/ and I want to have one like that for my site. (After a timeout, the first image slides out of the screen, then the second image flies out after it, and then a new pair fly in).
I've seen that IBM uses Dojo not jQuery. Is this built in effect in dojo?
I have knowledge in javascript (but not any library like jQuery/dojo) and I can make it myself the hard-way. But I wanted to know first if there is anything built in to do it?
I think you might be better off with dojox.widget.Rotator or even dojox.widget.AutoRotator.
The image slider on the IBM.com front page is built using Dojo, but not a out-of-box component of Dojo library. It's a customized component.
If you want to create image sliders using Dojo, take a look at existing out-of-box components in DojoX library (dojox.image). dojox.image.SlideShow is a good starting point.