Closed tung2744 closed 2 years ago
@tung2744 :shocked: I think it's quite not the direction I was looking for.
Actually, I don't intend to introduce any custom inputs with more than 10 - 20 lines of JS, so putting react here is definitely not align.
For UI interaction without page reloading or navigation, @Rubikium has helped achieved that in https://github.com/oursky/django-material-demo/pull/47. That's basically turbo plus SSR.
On the other hand, demoing custom UI is something essential, but a switch as boolean input might not be the best idea. Normally projects in Oursky are more UI driven, i.e. we implement based on what we see in design. But this project is trying to go the other way round. We try to tell designer what this UI framework is capable of. The mindset should be like, if the data is a boolean flag, it would be shown as check box in the form.
I don't want to give wrong impression to our developers that it is a good idea to write custom code while built-in features can easily replace, so I am not going to merge this PR
To demo custom components, I prefer we straightly find something more complicated, like autocomplete input, something that no built-in input can provide.
For embedding react component, I am not entirely against the idea. I can think of some more complicated UI component that we might want, for example, interactive calendar or timetable. However, they are usually more bound to domain-specific feature, thus requires higher degree of customisation. I mean this demo project is not about customisation (quite the opposite actually), we can still show developers how to do it with a big warning that they should always look for built-in and easier solution first. And don't demo any use case with it, good enough developers should know what they are doing and how to do it.
cc @rickmak
The mindset should be like, if the data is a boolean flag, it would be shown as check box in the form.
Agree. Actually I was just trying to setup a thing that enable us to make complicated components. The switch is just for proving this setup works.
The reason I embedded a react component is I think this is much easier than I create a autocomplete component by just using django template & hand write js. Using an embedded react component allow us to use material components in other packages with creating a new django widget.
Maybe I can update this pr to make a autocomplete component. Or if we don't want to demonstrate customized components I will just close this pr :sosad:.
@Steven-Chan
@tung2744 I expect the autocomplete input would not need react.
I think this PR could be used to demo integrating react pipeline for developers, but not using it to demo any UI. So I suggest replacing the switch component with a dummy one.
superseded by #67
@Steven-Chan Maybe setting up a webpack to build a js is over complicated in this project, I think I will just remove the react part. But I guess the custom widgets part can be keep because I think other developers may need some time to figure out how it works if there isn't a demo.
ref #51
The goal of this pr is to use components from other packages, and also provide a way to implement custom components in typescript. In this pr I only integrated a
Switch
component with minimal effort.In this pr I tried to integrate components from https://mui.com/material-ui/getting-started/overview/
It is basically implemented by following http://docs.viewflow.io/material_frontend.html#custom-components
Actually I think https://github.com/material-components/material-web should be a better choice but it looks like still in-progress, so finally I chose a react library.
You can see the outcome in http://localhost:3000/cms/polls/question/add/
Note: I didn't update the build script of pandawork demo because I didn't find the scripts in this demo.
TODOs:
@Steven-Chan Not sure if this is the correct way to go. Planning to add more useful components such as autocomplete input / combo box in the future if it is ok. See if you have any thoughts?