search

brakmic / purescript-redux

:alien: Redux Bindings for PureScript
MIT License
36 stars 9 forks source link

Fixing some building problems. #1

Closed Softsapiens closed 8 years ago

Softsapiens commented 8 years ago

Hi, first of all, thanks for your post and you code! It's very interesting...

During my build process some problems appear and I modify your config files to fix it. Perhaps are you interested...

Thanks again for share your work. Dani

brakmic commented 8 years ago

Hi,

Thanks for the info. These build problems are because of a bug with certain PureScript-Versions. The 'Primes' in the names of Variables are the source of these problems.

Perhaps you're using the standard 7.x Version of PureScript. I'm using the latest version, 8.x, which is still in development.

More info on the bugs here: https://github.com/purescript/purescript/issues/1767

It will be fixed in the next PureScript version: https://github.com/purescript/purescript/pull/1737

brakmic commented 8 years ago

I checked your configs. Indeed, there's one thing I omitted to include today. I was relocating Ractive.js, because it has nothing to do with Redux itself. Ractive.js is just a view layer and I moved it to scripts/ui. So I had to set it as one of the foreign sources in Gulpfile.js. I'll now update my Gulpfile but because your Pull-Request combines several different things I can't easily import it. Therefore I'll update the sources and then you could, if you have some time, check it out if the build problems are still there.

Thanks :+1:

brakmic commented 8 years ago

Also I saw you're putting all the source files under one array in Gulpfile.js. I split them between sources and demoSources. "Sources" are for the whole library stuff and "demoSources" are where, well, the demo apps live. That's why I build the 'backend' sources (Redux itself) with "gulp" only, but the demo with "gulp build-demo". Sometimes I simply want to rebuild the demo without rebuilding the library.

But this isn't written in stone and you may do it as you wish.

There are surely several cool ways of doing this.

brakmic commented 8 years ago

And one more thing, regarding "bundle-demo" and the relocation of the task "make-demo". Originally, this task was chained with "bundle-demo". Yes, you're right, it should be there but I experienced some strange behaviors like non-compiled sources despite my repeated "gulp build-demo" calls.

I'm not sure if I just had some other problems in the console at this moment but after having split them up I could always generate fresh builds.

So, just in the case you experience something similar: execute once "gulp make-demo" and then "gulp build-demo". For example, after the first checkout of the whole source tree, when you haven't built anything previously.

These are strange things and I assume they have something to do with the asynchronicity that's inherent to Gulp (which is, btw, a good thing but sometimes hard to manage...at least for me)

Kind regards and thanks again!

Softsapiens commented 8 years ago

Hi! Yes, I was using version 0.7.6.1 as my local installation, thats the reason why I added purescript 0.8.0 into package.json. I like to do what when the project use gulp, I think it's a great approximation, and makes the project independent of local installs. The same for babel libraries... in this case, I hadn't installed them previously.

I have added the demo sources/js into the arrays sources/foreigns in order to get compiled the modules into output dir. Previously, make-demo task didn't do anything ¿? I don't know why. Perhaps bundle-demo could depend on make task, and we could remove make-demo task and its two arrays of 'sources'. In my opinion for this kind of project structure it's a good solution, but that's up to you.

After changing make task, some compilation errors appeared. I have needed to put the some Purescript libraries into bower.json file in order to solve it.

Sorry but I don't follow you about the change of location of ractive. In my fork I have it into scripts/ui, and was that code who generates the compilation errors mentioned above.

I will test again when the changes are done. :+1:

Thanks and Kind regards

brakmic commented 8 years ago

In the beginning, Ractive.js was within the same directory structure like Redux (src/Control.Monad.Eff). But because it has nothing to do with the library itself (purescript-redux) I moved it to scripts/demo/ui. Just to make it less confusing for people who are only interested in Redux but not in Ractive.js.

It surely may be that someone would like to try purescript-redux with React.js, for example, or any other UI library. I didn't want to make Ractive.js look 'mandatory'.

That's why I moved it to demo/ui :smiley:

Kind regards and thanks for the corrections,

Softsapiens commented 8 years ago

Completely agree! this library must be independent of the ui framework. In that case, why don't you create a demo as a complete project (with its bower.json, package.json, gulpfile,...) although it was a folder inside this project, as it is now? in this way, it will not be necessary to add ui dependencies ("purescript-easy-ffi", "purescript-maybe", "purescript-unsafe-coerce",...) inside the main config files, and the demo will be a project template too.

Kind regards