When importing `styled` into a code component the template strings break other component styles.

[magbicaleman]

Framer X v39

Inside of my Block.tsx( a component from code), when I import styled and try to extend styles on my production component, it breaks all other styles. No errors or warnings.

import styled from "styled-components"
const X = styled(System.Block);

The code above does not break anything.

When I try to do the following below, this does then break my other component styles.

import styled from "styled-components"

const X = styled(System.Block)`
    color: red
`;

I'm not sure why this would be the case I'm not too familiar with the styled package.

[magbicaleman]

I just tried to create a new styled component, and not use it at all. This still breaks the styles for other components. Is this a TSX issue? I'm not too familiar with TypeScript to know if you can mix non-typescript code with typescript code.

import styled from "styled-components"

const A = styled.div`
    color:red;
`;

[addisonschultz]

@magbicaleman This is partially an issue with the way styled-components handles components that are nested and extended in the way you're approaching this. I'll have a play around and see if there is a way to get this working.

Relevant:

https://stackoverflow.com/questions/45142393/stopping-props-to-be-passed-on-to-child-with-styled-components?rq=1

https://github.com/styled-components/styled-components/issues/439#issuecomment-276420364

[magbicaleman]

The motivation to extend my "production" component styles in the framerX component is due to wanting to add rules for the framerX frame wrapper that gets added to each of my design items.

I don't want to add the following CSS to my production component's style rules, but I do want to add it in the FramerX coded component.

[data-framer-component-type=“SomeComponent”] > *,
[data-framer-component-type=“SomeComponent”] > [data-framer-component-type] {
    position: relative;
}

https://twitter.com/nvh/status/1159922078985916416?s=20

I guess in general there may be scenarios in where I don't want certain rules on my production component but do want to extend them when they are imported to FramerX. Although this really breaks the source of truth path that we are seeking, there might be special occasions in which we'd need this ability.

[addisonschultz]

I see what you mean. On that note though, if you try and add positioning into the styled component, there will still be a [data-framer-component] selector on top of of the component as it's container.

The positioning is the part you're trying to solve?

[magbicaleman]

I'm trying to make it as "web" default as possible, the wrappers have been a bit of a challenge. In our production, we wouldn't have the [data-framer-component] wrapper.

For example, when I import my production component into my FramerX "bridge" component and allow it to have multiple children, each child gets wrapped around the [data-framer-component], this kind of breaks some of my components features like flex.

What helps to get past that display flex, is making the [data-framer-component] position relative, but then I have the issue that these wrappers can be whatever width.

I created a video a few days ago, displaying what I'm attempting to accomplish:

• https://www.youtube.com/watch?v=M1KDO-e_Bfk

The main goal for me is that designers could use components as a source of truth, but front-end dev could somehow use what a designer designed as effortlessly as possible and just worry about writing the business logic.

[addisonschultz]

Yeah that makes sense. As you mentioned, we're close but there are a few things we need to fix before we can make this a reality. The biggest being able for us to use as much of the real DOM through our components and canvas, which we still need to solve (but are aware and are moving towards this).

Using Frames in Production isn't directly possible, but motion components handle much of the same: https://www.framer.com/support/using-framer-x/creating-real-apps/

Framer Motion components translate most of the functionality of Frames or other Framer elements, but the issue here is that you'll still get the same behavior with positioning in the context of Framer X.

It's unfortunate, but at least know we're aiming to get to a point where this is possible!