I'm building a simple text editor that relies on Draft.js for decorating the text (mainly highlighting). I really like how simple it is to build a reliable input that has custom syntax highlighting.
However, I do not like the fact that I have to expose the entire editor state to do this. I'd prefer to have an editor that has just a value property that takes a string and passes a string trough the onChange prop.
This seems a reasonable thing to be able to do, yet I'm dumbfounded by how hard it is to transfer selection state.
Because of how draft.js is implemented, I find this hard to do. I need to create a new editorState based on the value prop every time it changes, which is doable, But it is hard to transfer selectionState between the old editorState and the new one because the selectionState relies on opaque identifiers that are unique to each state.
Has anyone tried to accomplish this? Is draft.js overkill for this an should I use a simpler solution that also works? I'm only using the decorators so I guess it would not be super-hard to just rebuild that part.
Related
Pretty much the title, im trying to make a widget that contains some data and linecharts, i know this glance stuff is pretty new, so im not sure if its possible to do this.
Glance is limited by the RemoteViews capabilities, thus you cannot create custom views. Instead you would need to render a bitmap with your linechart and use it in an Image composable.
I believe some graph libraries out there allow to export a chart to a drawable/bitmap
New to Fluent UI React.
I have been tinkering around with the framework and read through all of its documentation that I can find. My understanding is that CSS-in-JS approach is encouraged when it comes to component styling. I see there are two ways to do so–via the styles prop and via the use of the mergeStyleSets utilities function + the className prop. Here is a codepen to illustrate what I mean here.
My question is, do they serve different use cases or are they pretty much the same? How do I decide which one to use? Thanks.
I've tried both and am leaning more toward mergeStyleSets because it gives me one way to predictably target everything and I don't have to learn the "magic class names" buried deep within each component and what it does or does not affect. Having said that, for certain key components, like DataGrid, there's a lot of styling involved and the classes exposed are not too difficult to learn and are helpful for getting the best out of those components.
This is particularly the case when you have to do selectors for things like "hover" or "active" or "before/after". Trying to get that working via magic class names exposed by "styles" was much more confusing for me than using the "mergeStyles" approach on the raw HTML directly.
So for me, I've been cherry picking from the framework, using it for color themes, elevation, and highly complicated components like DataGrid, but not for things like Stack or Stack Item.
I'm using Ext Js 4.1.1.
In many of the Ext JS widgets I am using, I am required to reuse data. For example, the items collection for buttongroup in top toolbar may be repeated in menu bar on the left side. For manageability, I should be able to have the array for items collection defined in a separate file (which could potentially follow the class naming convention for auto loading).
The approach I tried is that I am creating a class that has statics. Each static function returns an array that can be assigned to items collection of the widget. This works but I believe that using a class is an overkill if I can just use an array. Any suggestions?
Not sure if it will be useful to create separate objects for storing configuration for toolbars, buttons groups and etc. In the context of the extjs in almost all cases you need not only manage configuration but also behavior of a component.
The best way for me here - creation of generic/basic predefined classes, where you can state not only configuration but work around the behavior, add you'r custom events and process any unexpected results. After it you can easily reuse and extend it easily.
For instance you have a menu or a toolbar with 3 items A, B, C. For sure you need to know wherever you use it what was clicked (for instance) A, B or C. Creating a class and manages required events you can fire you own events which will tell you what was clicked and it is much easier to use in any context where this component will be used. Add post and pre processing, template methods and etc...
Creating a big file just with configuration is not readable and not extendable, will be a case whre you will need to add functionality and behavior to all such generic components and it will be not easier to do with just arrays or simple configs. Separating even just simple general components having just simple configuration (in the beginning) will bring more expressive in the code structure and readability and in the later time gives you the power to manage it.
Pure configurations can just keep the code accurateness and re-usability but what about behavior for in almost cases you need to control..
The design, maintainability and extensibility are very important points in every big web-applications and in context of extjs 4.
I have a Button in Silverlight. I need to change its style at runtime. The style of this Button needs to change multiple times during the life of the application. Is this possible in Silverlight? If not, what is a good workaround?
Thank you!
Consider using the VisualStateManager to change the state of the button as appropriate.
You could create your own states for each of the different styles you wish to show.
Yes, it's possible, but I'd think hard about what exactly you're trying to do by changing the style itself because there's probably an easier way. You've probably already run into the fact that you can't simply assign a new style to the button with something like MyButton.Style = (Style)FindName("NewButtonStyle"). So you do need some kind of alternative.
The VisualStateManager is the first and easiest way of handling most kinds of changes that you would normally want to do to a control. You can pretty easily set changes to occur on the normal sorts of visible states (hover, focus, mousedown, mouseup) and it'll animate those state changes correctly from whatever state you're in to whatever other state you need.
If the kind of change you're looking for is more extensive, changing the type of control to, say, a ContentControl and then catching the mousedown/mouseup events from there might be a better workaround. This is obviously a bigger deal (and you lose the simplicity of having a button), but you'd be able to get whatever changes you wanted to pretty easily by just swapping out the Content property.
Somewhere between the two (and something I'll mention because it's possible, not because I recommend it) would be to actually manipulate the Style definition itself. The Button will pick up the changes and adjust itself. I'm going to repeat myself here though: I don't recommend this and I can't envision a scenario where I'd prefer doing this over using the VSM or using something other than a Button entirely. But it is possible to get into Application.Current.Resources["Style"] as Style and muck about with whatever you please. The bigger question then is why and whether what you're doing can be done some other way that would make more sense for whoever's going to maintain your code later. Personally, I expect Styles to be pretty static and I think that's the general consensus too.
Sure you can....
if you have a style stored locally you can access it like that :
rec1.Style = (Style)this.Resources["style1"];
I see a 'Tag' property in the design view for most WinForms controls. I have never used this tag and want to know why I would want to use it.
It allows you to store some of your own data with a control. It mostly useful in tree controls where you might want each node/leaf to have some extra data associated with it. This way when you click on a node you can perform an action relevant to the node.
Its a general "catch-all" for additional data you wish to store with a control.
I too have never used it.
We perform heavy use of tags. We have some methods for checking input, and these methods checks whats in the tags in order to know what control to perform.
IE: if a textbox has RQ=1;DT=int;MAX=100
the automatic method knows that this text can not be left blank, that should accept only integers within 0 and 100.
We have a complete pseudo declarative language for this.
Kind of useful!
More specific for your question, Tags are for your use.
for example you have a lot of buttons with single method handling clicks. then at handler you have do differentiate them from each other. So you put some sort of id (or reference) and then access it there.