Plan future for MADE App Components
tom-made opened this issue · comments
MADE App Components has gained an interest in the community but it has been built in a way that makes it complex to get started with where many parts are wrapped up in large components.
With minimal available public documentation, how-to guides and samples on the project, we believe that there is still a lot of work to go to get MADE App Components ready for public release.
As part of this issue, we need to discuss what is vital to the project, what can be stripped back and re-architected, and what needs adding to make this the go-to framework for starting with making applications for Windows, Android and iOS.
I will keep this section up-to-date with a list of requirements as we progress and will start breaking them out into separate tracked features/issues.
Requirements.
- Discuss
@jamesmcroft if you have any input, it would be greatly appreciated!
I think there are some fundamentals that are required here for app development, particularly if our end goal is to build cross platform apps and help developers doing that.
One thing off the top of my head would definitely include MVVM and combining that with creating a common way for developing data bound pages and the navigation of them. This is possibly the most important feature and will create the building blocks for apps.
Building custom controls is probably my second most wanted feature. I take pride in developing custom controls but it can be daunting for some developers, particularly those new to platforms, to build their own controls. I think we had a great plan going with the work we already started for building custom controls. With better documentation, examples and more controls in the project, this would be great.
Then thinking back to the XPlat project I am working on, any common APIs for cross-platform development would make the world of difference for getting those common scenarios for apps built rapidly, such as file storage, geolocation etc.
Some of the additional work we've done in this project around extension methods is great, but I think it's probably a low priority. Particularly because these again can be very confusing to developers without the correct documentation and example usages.
More than happy to help flesh out some of these ideas if they make sense.
@tom-made I think you've touched on this slightly with your initial comment, but I think the first steps are to define what we want our initial packages to be and start separating out those components. It would be silly to throw away the work we've already done to date.
I understand we never got a full v1 out but we already know that some apps are already using the pre-release components.
Just a thought.
@jamesmcroft no, I completely agree. The plan isn't to scrap everything that's been done. What I want us to do for this exercise is to come up with a defined structure, have it written down and push this throughout the project.
It won't only cover what the project contains but it will be a set of things that we work towards such as how we define a good PR and how do we track issues and feature requests.
I feel that before we can do all that though, we need to define what it is that this project is going to achieve and start from there.
The points you've raised are great. I'd like to highlight your comment on pages and controls. Developing views is at the core of any application and I agree 100% with this as being one of the first building blocks.
If we can jot down all of the building blocks we think developers will need to create great apps, we have ourselves an awesome project.
I think I might spend the weekend defining some rough guidelines and send them your way @jamesmcroft.
@tom-made No problem. If there's anything I can do to help, just let me know!
@jamesmcroft I'm going to fire up another branch, clear everything back and we can work from there
If you could take a look at the changes I've quickly put together @jamesmcroft that would be great.
Do you have thoughts on how to do docs? I know we previously used Slate but the support for anyone who uses Windows to build and deploy the site is lacking. I've taken a look at some Jekyll alternatives but again, they all have a similar problem.
I think the changes aren't too dissimilar from what we had before. I think the biggest work will come from the restructure itself.
As for docs, I have been looking at docfx recently for a work project. It looks promising particularly as our project is .NET
@jamesmcroft you previously commented about XPlat. Do you think that this works well as it currently is as an entirely separate entity or could you see that being a part of MADE? Just a thought I had.
The only problem I could see with merging XPlat into this project is the confusion for existing users. I think it works best as its own thing for now.
@jamesmcroft no worries.
So, now that we have the basics back in place, let's come up with some projects that make sense.
I recommend that we try and keep them as lean as possible. Doing this will allow developers to make easier decisions to take the parts they actually need.
I can put a rough solution with empty projects together if needed.
Are we still aiming to support .NET Standard 2.0 minimum?
@jamesmcroft that's great. I'll take a look once you've done.
.NET Standard 2.0 is probably best now that the next version of Windows will be available to dev against so we can support at least 2 Windows versions. I think multi-targeting also where we can. I noticed this was something we started doing.
So I've made some changes and put a basic structure for you to review for the first part.
Essentially, the projects will all be MADE.App namespaces. We are going to aim to provide building blocks as packages so these should be stripped back to their bare bones.
Also, I've added the docfx dev tooling to the projects to see what it does. This will need further investigating and customizing to suit our needs but it seems to generate the site.
So I've started looking at some of the components that require multi targeting and there appears to be issues with docfx.
If multiple targets are present, it doesn't appear to generate the site.
@jamesmcroft it looks like this issue has been raised with the docfx team already. I did a similar test and found the same issue so I've pinged a message on that thread to see if there is a solution.
So I've updated the NuGet packages for dotfx but it still doesn't appear like there is any progress that has been made to support multi targeted projects that I can see.
After the conversations we've been having, I'll close this off. I've created a separate project for covering documentation (#36)