(version) 1.0.0-alpha.21
Every component has required property: 'classes' for css-in-js purposes.
But as an end-user I do not want to be forced to specify this prop for every component. It's just not convenient.
I get unnecessary linting warning:
How to solve this problem? Should it really be required?
That's an issue with the internal of your IDE, he isn't able to catch that the withStyles() Higher-order Component is providing the classes property.In the other words, it doesn't hamper you to use these components.
Related
I'm currently looking for a way to capture only svelte components on the DOM tree during development mode. I can see that we I run npm run dev all elements and conponents have the "class='svelte-somerandomID'". Does this only happen in development mode?
Yes, it's only in during development that all elements get a scoping class -- and only with some tools. Actually it's a hack we've added in vite-plugin-svelte to enable more power CSS only HMR.
The classes you're referring to are what Svelte uses to make the CSS in a component apply only to the elements of this component. It adds a class that is unique to the component to all elements that can be affected by the component's CSS, and it also modifies your CSS rules to add the same class to them.
Normally the compiler only adds the scoping class to elements that can actually be targeted by the existing CSS rules in your component. If you really want all the elements in a component to have the scoping class, you can use the same trick that I linked to above: add the following rule to your component's CSS.
* {}
By default the generated class names are a hash of the component's CSS content. But you can also customize them with the cssHash compiler option. Note that vite-plugin-svelte also changes how the class names are generated, to be based on the file name instead of the content.
Since every element in the component would be targeted by this roule, this will cause the Svelte compiler to add the scoping class to all the elements.
If you wanted to automatically generalize this to every element of every component, you may want to do it with a preprocessor (if you need some inspiration, the code I've linked too actually implement this with a preprocessor).
I'm not sure if this is what you really want though. For one thing, only elements get a scoping class: components don't get a scoping class, because components don't have dedicated elements in the DOM (only the ones you may or may not add via the component's markup). The above trick would only give you a mean to select every element of a Svelte component. There might probably be easier or cleaner ways to achieve what you really want. For example, a simple wrapping component, or an action, that would use wrappingElement.querySelectorAll('*') or something...
With the release of the .TagWithCallSite() method in EF Core 6.0 I was wondering if there is a way to apply this globally on every query run via a DbContext in some way?
It would be much better to apply this across the whole project without having to put it on each query individually.
TagWithCallSite accepts parameters marked with CallerFilePathAttribute and CallerLineNumberAttribute which are filled in by compiler (or manually if needed) during build so it is impossible to set up globally.
No, you cant't do that.
When you explicitly define TagWithCallSite(), complier automatically fills default parameters filePath and lineNumber. It is not possible to define that for all queries because compiler do not store such information in Expression Tree.
I have a final-form backed grid built using ag-grid. Ag-grid takes renders which in my case are Fields wrapped with FormSpy's. Using pre-hooks version of final-form works but I had a few problems so I upgraded to the most recent and received the "[X] must be used inside of a component" error.
I used react devtools and sure enough, my custom Fields renderer / editor was being moved outside of context as leafs at the end of the tree. My question is, is there any workaround to make this work? Is there any way to subscribe to a specific context? Bit of an anti-pattern, I know, but I'm running low on ideas.
Example
This is the version with older final-form packages -- https://codesandbox.io/s/final-form-ag-grid-lbq7f
I was having problems using formik because ag-grid-react doesn't support React's context API without a prop, i.e. reactNext={true}. One other suggestion don't put gridApi in state, instead pass a ref to AgGridReact like:
const gridApi = useRef();
<AgGridReact
{...}
ref={gridApi}
/>
I am using the PostSharp solution for INotifyPropertyChanged by decorating my business classes with the [NotifyPropertyChanged] attribute.
All works fine.
Now I wrote a custom aspect that handles property changes so that I get some custom flags set when some special properties change. This aspects is named [HandlePropertyChanged] and works when used alone.
Now I try to use both aspects in combination. As I read on the PostSharp page I can manually order them to ensure a fixed order by using
[NotifyPropertyChanged(AspectPriority = 0)]
[HandlePropertyChanged(AspectPriority = 1)]
In this case, I can build my solution, but because "NotifyPropertyChanged" runs before "HandlePropertyChanged", the changes on my properties are already done and the custom logic does not run correctly.
If I try this
[HandlePropertyChanged(AspectPriority = 0)]
[NotifyPropertyChanged(AspectPriority = 1)]
my build fails with the error at the bottm of the text (see below).
Best would be to simply do what NotifyPropertyChanged does in my custom aspect and forget about the PostSharp aspect
Is this possible?
0: Error C:\Source\WAVE\WAVE.Data.Contracts\Entities\Base\EntityBase.cs (17,16) PS0115: Conflicting aspects on "TopMotive.WAVE.Data.Contracts.Entities.Base.EntityBase`1": according to aspect dependencies, transformation "Instantiation of aspect PostSharp.Patterns.Model.NotifyPropertyChangedAttribute" should be located both before and after transformation "Instantiates binding collection for field "PostSharp.Patterns.Model.NotifyPropertyChangedAttribute/LocationBindings".".
This bug is fixed in PostSharp 5.0.52 and PostSharp 6.0.16 RC.
Try superior and free alternative: Stepen Cleary's Calculated Properties.
https://github.com/StephenCleary/CalculatedProperties/blob/master/README.md
I used both in production and found it to be far better than PostSharp's aspect.
Also from PostSharp docs:
"If a property getter calls a virtual method from its class or a delegate, or references a property of another object (without using canonical form this.field.Property), PostSharp will generate an error because it cannot resolve such a dependency at build time. The same limitations apply when your property getter contains complex data flows, such as loops, or calls to methods (except property getters) of other classes.
When this happens, you can either refactor your code so that it can be automatically analyzed by PostSharp, or you can take over the responsibility for analyzing the code"
None of those limitations apply to Calculated Properties. It can do loops, virtual methods, LINQ to objects, basically any runtime dependencies that you can imagine doesn't matter how indirect. Dependency graph rewires itself at runtime and just works without any ceremony. They are also fast.
I'm just going through the GWT Tutorial and one point which just don't understand is when and why to use dependent secondary styles. If I define a style in the .css stylesheet, and use the addStyleName method it seems to have the same effect.
E.g. applying a secondary dependent style to a button or applying the it as a non-dependant style seems to yield the exact same results.
Basically the dependent name is more general, since it's calculated at runtime. You can add a dependent name of "highlighted" to any Widget without knowing what it is, and GWT will come up with the appropriate css class name for you. You don't have to hard code button-highlighted, select-highlighted, mycustomthing-highlighted in GWT this way (you do still need to create them all in your css code).