Not looking for any recommendations, just an objective assessment if any JavaScript framework can be type-checked with Flow in the current state.
With Flow decreasing in popularity compared to TypeScript, framework declaration files tend to be written in TypeScript, and conversion is not trivial nor automatic. Is there still a framework that works well with Flow type inference, or for which you can write your own framework declarations on the fly? Or is Flow mostly used for framework-agnostic business logic today?
So the main one is react, given that its type defs are built directly into the flow project. The other which I haven't looked into personally is Vue, given that it's written in flowtype. But I cannot confirm how to get their type defs as I haven't used it personally.
But even if a library doesn't ship with type defs, it doesn't mean it doesn't support flow. One clear example is styled-components, it's built in flow with first class flow support but do not ship out of the box. Instead their defs are shipped via flow-typed. I'm not sure what their reasoning is, but most likely it's to remove coupling of flow version with styled-component version, and consumers can upgrade each independently.
Overall if you can't find a lib def readily, either not many people use it with flow or the consumers don't bother and just use the types as any. Since there are many projects in the world that don't use any static type checker, having partial static analysis may be good enough.
Answering my own question, I think looking into the flow-typed repo and look for a particular lib or framework will answer this. No recent update = no support, unless you have time and interest to make a PR yourself.
https://github.com/flow-typed/flow-typed
Related
Have a question, never used roslyn before so i'm wondering about maybe experimenting it in a task that i would normally use reflection.
I'm given an external dll, i need to go over some classes in that dll and extract some metadata on them.
Like for example, the class name, property names and types and such.
I would normally use reflection to do it. Should be a super simple task.
But i've been told that this can be achieved using roslyn.
Can it? From what i'm seeing, Roslyn can parse a class but i need to give it the code that represents this calss as text. How would i get the code as text in an already complied code?
Is that even a reasonable scenario to use roslyn? Does it worth the effort?
Thanx!
If all you need is information that's already easily available via reflection, then Roslyn is likely to make it much harder. There's quite a lot of setup required, which can be error-prone and brittle in the face of new releases, in my experience.
I would typically use reflection for anything where the starting point is an assembly. When the starting point is source code, that's when it makes more sense to use Roslyn.
When Roslyn is the right tool for the job, it's amazing - but it doesn't sound like that's the case here.
When you using Roslyn, you have lexical info and symbolic info.
The lexical info won't help you, you must use the symbolic info, for that, you must have compilation and you can create it for compiled code.
With the compilation, you indeed can achieve types info but not runtime info. Anyway, using reflection for this is much straight forward.
When your mission is related to tree transverse or syntax rewriting, Roslyn is perfect, but for metadata info, it's the wrong usage.
It depends on your specific needs but maybe there are other "tools" that more suitable for your task (e.g. cecil or dnlib)
I have fairly significant application written with Dart and Polymer which uses reflection in a factory method and runs fairly well in Dartium. The factory generates subclass instances using the subclass name passed to it as a parameter.
I'm fine with never generating Javascript and forcing my users, if any, to use Dartium. I'm also fine with modifying any #MirrorsUsed annotations when the list of instantiable subclasses changes. The page at http://dovdev.com/smoke-and-mirrors/ seems to imply that performance and/or codesize can be greatly improved, even in Dartium, by the use of Smoke.
How much does Dartium, or the Dart analyzer, do when running a Dart app? Will Smoke, or even just #MirrorsUsed annotations, do anything for an app in Dartium?
This sounds like you want to use Dartium in production which is definitely a bad idea.
Currently dev_compiler, a fast incremental Dart-2-JS compiler is work in progress to allow to use Chrome as development browser and to make Dartium redundant and discontinue it eventually.
In Dartium #MirrorsUsed() and Smoke don't matter.
If you are using an in-house application where you even consider using Dartium for production, perhaps the code-size effect of using mirrors might not even matter too much.
If we had a defined hierarchy in an application. For ex a 3 - tier architecture, how do we restrict subsequent developers from violating the norms?
For ex, in case of MVP (not asp.net MVC) architecture, the presenter should always bind the model and view. This helps in writing proper unit test programs. However, we had instances where people directly imported the model in view and called the functions violating the norms and hence the test cases couldn't be written properly.
Is there a way we can restrict which classes are allowed to inherit from a set of classes? I am looking at various possibilities, including adopting a different design pattern, however a new approach should be worth the code change involved.
I'm afraid this is not possible. We tried to achieve this with the help of attributes and we didn't succeed. You may want to refer to my past post on SO.
The best you can do is keep checking your assemblies with NDepend. NDepend shows you dependancy diagram of assemblies in your project and you can immediately track the violations and take actions reactively.
(source: ndepend.com)
It's been almost 3 years since I posted this question. I must say that I have tried exploring this despite the brilliant answers here. Some of the lessons I've learnt so far -
More code smell come out by looking at the consumers (Unit tests are best place to look, if you have them).
Number of parameters in a constructor are a direct indication of number of dependencies. Too many dependencies => Class is doing too much.
Number of (public) methods in a class
Setup of unit tests will almost always give this away
Code deteriorates over time, unless there is a focused effort to clear technical debt, and refactoring. This is true irrespective of the language.
Tools can help only to an extent. But a combination of tools and tests often give enough hints on various smells. It takes a bit of experience to catch them in a timely fashion, particularly to understand each smell's significance and impact.
You are wanting to solve a people problem with software? Prepare for a world of pain!
The way to solve the problem is to make sure that you have ways of working with people that you don't end up with those kinds of problems.... Pair Programming / Review. Induction of people when they first come onto the project, etc.
Having said that, you can write tools that analyse the software and look for common problems. But people are pretty creative and can find all sorts of bizarre ways of doing things.
Just as soon as everything gets locked down according to your satisfaction, new requirements will arrive and you'll have to break through the side of it.
Enforcing such stringency at the programming level with .NET is almost impossible considering a programmer can access all private members through reflection.
Do yourself and favour and schedule regular code reviews, provide education and implement proper training. And, as you said, it will become quickly evident when you can't write unit tests against it.
What about NetArchTest, which is inspired by ArchUnit?
Example:
// Classes in the presentation should not directly reference repositories
var result = Types.InCurrentDomain()
.That()
.ResideInNamespace("NetArchTest.SampleLibrary.Presentation")
.ShouldNot()
.HaveDependencyOn("NetArchTest.SampleLibrary.Data")
.GetResult()
.IsSuccessful;
// Classes in the "data" namespace should implement IRepository
result = Types.InCurrentDomain()
.That().HaveDependencyOn("System.Data")
.And().ResideInNamespace(("ArchTest"))
.Should().ResideInNamespace(("NetArchTest.SampleLibrary.Data"))
.GetResult()
.IsSuccessful;
"This project allows you create tests that enforce conventions for class design, naming and dependency in .Net code bases. These can be used with any unit test framework and incorporated into a build pipeline. "
I'm in the middle of creating a fairly large flex application, and over time, it's started to edge toward unmaintainability.
I'm using 3 external library projects which are still small enough to remain maintainable and reusable, but the main project seems to be impossible to keep organized.
Part of the problem seems to be that I have about 30 objects inheriting from a single abstract superclass type object. All of child objects have both a logic component and a ui component which are tightly integrated to each other. The superclass object has about 60 shared methods and properties, most of which can be overridden in any of the child classes, a few of which should be overridden in all child classes.
To add to the complexity, these have to communicate between themselves, and this is usually via the container object they reside in. Additionally, the main project has to create value objects out of these so they can be sent to a FlourineFX backend for storage, and additional authentication/authorization logic.
I've created much larger projects in languages from old MS BASIC (pre VB), Ada, VB (3 to .Net 1), C++, and C# without this problem. (well, old VB tended toward this problem because of the same tight integration between UI and logic) So, is there any thing I'm missing, or is there any best practices that I can implement? (even if that means rewriting entire swaths of code)
And yes, this may be an extension to this conversation.
Do you use any framework implementations in this project? A framework would help modularise a lot of this complexity and hopefully remove a lot of the dependencies you seem to have between the application logic and views.
I'm a massive advocate of the RobotLegs framework which implements the mvcs pattern and offers dependency injection for use throughout your project. There are others out there such as pureMvc, Cairngorm, Mate. Have a look around and see which best suits your project.
It sounds to me like you really need to do a big refactor which is a risky process in such a large project. It could be well worth it if you're struggling to maintain it. If you are going to refactor definitely refactor into a framework. It's probably the area that will give you most bang for your buck (pound for the brits ;) )
James Hay's conversation starter is a good one, but for HUGE applications I would take time to test and consider memory management for some of the suggestions in that answer/conversation. RobotLegs is great and all, but I would worry about 'over-singletonization' and potential memory management issues that it would create (though I have to admit that I've never used and avoided robotLegs because of it's use of singletons).
If you were thinking IoC and dependency injection (like that which robotLegs provides), I'd suggest a look at swiz -- I really like the new 'instance-direction' swiz has taken. My only issue with it (in the current beta) is they have some cleanup issues, though these issues are easy enough to remedy (look through their source and any time you completely remove a component from the stage you'll have to play the profiling game and make sure everything is getting cleaned up --- we had to create temp functions to remove the changewatchers and destroy 'display list bean instances' until they get that stuff fixed).
The project I lead had many of the potential issues you must be worried about. Our ERP app has thousands of modules and the thing is running on client machines for hours/days at a time, constantly loading and unloading modules. Garbage collection and memory management were and is THE issues.
As for using mate, the annoying carhorn, or pureMVC, we created our own framework two years ago. It borrowed ideas from cairngorm, but overall my suggestion is to use whatever you can quickly learn, understand and teach while thinking about garbage collection. Our internal Model and View classes now use swiz (for newly developed modules) and this has made maintainability and code readability super smooth.
I hope my blabbing has helped at least a bit.
Best of luck.
It seems like you just need a clean separation of UI and domain components. Look into the component guidelines and the Presentation Patterns discussed by Martin Fowler, especially the Presentation Model.
To bring these pieces together, you might want to use an IoC container like Spring ActionScript. This is a non-intrusive framework that allows you to keep layers separated.
Don't let a framework get in your way. I've seen massive misuse of frameworks like PureMVC and Cairngorm mainly because apply them in an all-or-nothing fashion.
I have a large codebase that targetted Flash 7, with a lot of AS2 classes. I'm hoping that I'll be able to use Flex for any new projects, but a lot of new stuff in our roadmap is additions to the old code.
The syntax for AS2 and AS3 is generally the same, so I'm starting to wonder how hard it would be to port the current codebase to Flex/AS3. I know all the UI-related stuff would be iffy (currently the UI is generated at runtime with a lot of createEmptyMovieClip() and attachMovie() stuff), but the UI and controller/model stuff is mostly separated.
Has anyone tried porting a large codebase of AS2 code to AS3? How difficult is it? What kinds of pitfalls did you run into? Any recommendations for approaches to doing this kind of project?
Some notable problems I saw when attempting to convert a large number of AS2 classes to AS3:
Package naming
class your.package.YourClass
{
}
becomes
package your.package
{
class YourClass
{
}
}
Imports are required
You must explicitly import any outside classes used -- referring to them by their fully qualified name is no longer enough.
Interface methods can't be labelled 'public'
This makes total sense, but AS2 will let you do it so if you have any they'll need to be removed.
Explicit 'override' keyword
Any functions that override a parent class function must be declared with the override keyword, much like C#. Along the same lines, if you have interfaces that extend other interfaces and redeclare functions, those overrides must be removed (again, as with public, this notation didn't make sense anyway but AS2 let you do it).
All the Flash builtin stuff changed
You alluded to this above, but it's now flash.display.MovieClip instead of just MovieClip, for example. There are a lot of specifics in this category, and I didn't get far enough to find them all, but there's going to be a lot of annoyance here.
Conclusion
I didn't get to work on this conversion to the point of success, but I was able in a matter of hours to write a quick C# tool that handled every aspect of this except the override keyword. Automating the imports can be tricky -- in my case the packages we use all start with a few root-level packages so they're easy to detect.
First off, I hope you're not using eval() in your projects, since there is no equivalent in AS3.
One of the things I would do is go through Adobe's migration guide (which is basically just an itemized list of what has changed) item by item and try to figure out if each item can be changed via a simple search and replace operation (possibly using a regex) or whether it's easier to just manually edit the occurrences to correspond to AS3. Probably in a lot of cases (especially if, as you said, the amount of code to be migrated is quite high) you'll be best off scripting the changes (i.e. using regex search & replace) and manually fixing any border cases where the automated changes have failed.
Be prepared to set some time aside for a bit of debugging and running through some test cases as well.
Also, as others have already mentioned, trying to combine AS2 SWFs with AS3 SWFs is not a good idea and doesn't really even work, so you'll definitely have to migrate all of the code in one project at once.
Here are some additional references for moving from AS2 to AS3:
Grant Skinners Introductory AS3 Workshop slidedeck
http://gskinner.com/talks/as3workshop/
Lee Brimelow : 6 Reasons to learn ActionScript 3
http://www.adobe.com/devnet/actionscript/articles/six_reasons_as3.html
Colin Moock : Essential ActionScript 3 (considered the "bible" for ActionScript developers):
http://www.amazon.com/Essential-ActionScript-3-0/dp/0596526946
mike chambers
mesh#adobe.com
My experience has been that the best way to migrate to AS3 is in two phases - first structurally, and second syntactically.
First, do rounds of refactoring where you stay in AS2, but get as close to AS3 architecture as you can. Naturally this includes moving all your frame scripts and #include scripts into packages and classes, but you can do more subtle things like changing all your event listeners and dispatchers to follow the AS3 flow (using static class properties for event types, and registering by method rather than by object). You'll also want to get rid of all your "built-in" events (such as onEnterFrame), and you'll want to take a close look at nontrivial mouse interaction (such as dragging) and keyboard interaction (such as detecting whether a key is pressed). This phase can be done incrementally.
The second phase is to convert from AS2 to AS3 - changing "_x" to "x", and all the APIs, and so on. This can't be done incrementally, you have to just do as much as you can in one fell swoop and then start fixing all the compile errors. For this reason, the more you can do in the first phase, the more pain you avoid in the second phase.
This process has worked for me on a reasonably large project, but I should note that the first phase requires a solid understanding of how AS3 is structured. If you're new to AS3, then you'll probably need to try building some of the functionality you'll need to be porting. For example, if your legacy code uses dragging and drop targets, you'll want to try implementing that in AS3 to understand how your code will have to change structurally. If you then refactor your AS2 with that in mind, the final syntax changes should go smoothly.
The biggest pitfalls for me were the parts that involved a lot of attaching, duplicating and moving MovieClips, changing their depths, and so on. All that stuff can't really be rearchitected to look like AS3; you have to just mash it all into the newer way of thinking and then start fixing the bugs.
One final note - I really wouldn't worry about stuff like import and override statements, at least not to the point of automating it. If you miss any, it will be caught by the compiler. But if you miss structural problems, you'll have a lot more pain.
Migrating a bigger project like this from as2 will be more than a simple search and replace. The new syntax is fairly similar and simple to adapt (as lilserf mentioned) but if nothing else the fact that as3 is more strict and the new event model will mostly likely cause a lot of problems. You'll probably be better off by more or less rewriting almost everything from scratch, possibly using the old code as a guide.
Migrating from as2 -> as3 in terms of knowledge is fairly simple though. If you know object oriented as2, moving on to as3 won't be a problem at all.
You still don't have to use mxml for your UI unless you specifically want to. Mxml just provides a quick way to build the UI (etc) but if you want to do it yourself with actionscript there's nothing stopping you (this would also probably be easier if you already have that UI in as2 code). Flex (Builder) is just a quick way to do stuff you may not want to do yourself, such as building the UI and binding data but essentially it's just creating a part of the .swf for you -- there's no magic to it ;)